Open Stack

On 24/01/17 21:36, Andreas Jaeger wrote:
> On 2017-01-24 14:22, Tom Fifield  wrote:
>> On 24/01/17 20:53, Andreas Jaeger wrote:
>>> On 2017-01-24 13:48, Tom Fifield  wrote:
>>>> On 24/01/17 20:47, Andreas Jaeger wrote:
>>>>> On 2017-01-24 13:44, Tom Fifield  wrote:
>>>>>> Top posting with intent :)
>>>>>>
>>>>>> We have someone who is representing a class of people that are almost
>>>>>> certainly more than 5% of our users and we chose not to help? No two
>>>>>> ways about it - with the minimal/once-off effort involved, that is
>>>>>> just
>>>>>> plain wrong.
>>>>>>
>>>>>> To fix Icehouse docs not existing, all one would need to do is copy
>>>>>> from
>>>>>> the old server to the new. We broke this, and we should fix it.
>>>>>
>>>>> And the fix is a redirect like we did for all previous releases.
>>>>
>>>> Except that isn't a fix - see the comments from your users :)
>>>
>>> Tom,
>>>
>>> we retired Icehouse in April 2016 already. And even before that there
>>> was no way to go from docs.o.o/index.html to any Icehouse content.
>>>
>>> This is the first report of an Icehouse user - that somehow had old
>>> bookmarks or whatever obsolete link that pointed to an Icehouse
>>> Configuration reference page,
>>
>> The thing is - the Icehouse (or Juno, or Kilo, or Liberty) configuration
>> reference is not 'old' or 'obsolete' for these users. It's an integral
>> document to keep their cloud running, or prepare for their upgrade to a
>> newer version. It's entirely valid for them to bookmark a link, or
>> follow an Ask OpenStack posting that sends them to a useful page.
>>
>>
>> The OpenStack docs team is not in the position to make the decision
>> about when a cloud is online, offline, ready for upgrade, insecure,
>> unstable or obsolete. It exists to serve the users who are in that
>> position. As such, content must remain until when our users no longer
>> need it. It's surprising to see how much resistance there is to this
>> idea, given it takes very minimal effort to keep an existing HTML page
>> online :) Our best data on users indicates that we no longer need
>> Austin, Bexar, Cactus or Diablo, but there are still significant numbers
>> on Icehouse and later.
>>
>> So, why not help Alvaro? Martin? Cristina? Randy? Mikhail? Renato?
>> Christian? Tomo? Graeme? Vaibhav? These are just a few of the people
>> running Icehouse that need this doc to do their job. How about it?

Thanks for replying - I'm glad to see interest in helping these folks.

> Btw. Christian is the one that made the change to EOL the docu.
>
> We have in the past redirected old content - up to havana - and forgot
> about that in Icehouse. So, you're arguing here for a change of
> direction and not for the status quo!

Awesome without trying ;)

> Tom, I'd rather fix the general problem instead of fighting single
> fires. So, what's the proposal you want to make for older documentation
> and how can we implement that - and retire it?

For now, what I would recommend is:

0. Acknowledge the install guide as special and basically that guide 
should follow upstream EOL. Any new installs should be a supported 
version - helping people keep existing clouds going is the primary 
archive interest for upstream EOL'd releases.

1. For other guides, keep the docs (in place, same URLs etc) for a 
version around until there aren't enough users on the version to warrant 
it, based on user survey data. (This includes fixing any versions broken 
by the server move)

2. We don't touch anything for the EOL'd stuff. Incoming bugs on EOL'd 
versions are closed as wontfix. If something for an old version goes 
very wrong and it stops publishing, we might abandon it, or throw up a 
redirect to a PDF or something.


For the future:

3. Stop the bit of the redirect business that users don't like and do 
awesome/best-practice/world-leading things that let users switch between 
releases for a particular page. This will only be possible with a change 
in how we work (eg content moves or deletions become a something where 
consideration is needed for the archive), perhaps more significant than 
the coding effort required.