String Freeze

[Matthew East]

2009/3/26 Richard A. Johnson <nixternal at ubuntu.com>:
> On Thursday 26 March 2009 12:39:40 Matthew East wrote:
> [...]
>> Erm, no you won't - if string freeze is 1 or 2 days prior to the Beta
>> Release, then you won't be able to upload the documents at that time,
>> because it will be in Beta Freeze, and uploads are only permitted
>> during that period if they fix a bug that is milestoned for the beta
>> release. Uploads are particularly closely scrutinised in the 1-2 days
>> before the Beta Release, so there is no way a regular *-docs upload
>> would be permitted.
>
> Filing an FFe for docs isn't all that difficult, as I have done it in the past
> for Kubuntu docs. Milestone all of your ubuntu-docs bugs for Beta release, so
> that covers one of the details. The other part in the exception is to
> "demonstrate strong rationale and minimal risk." That is actually the easiest
> part.

I'm a bit confused. In your first email you talked about how difficult
it is to justify a *-docs upload during the Beta Freeze. You said "A
documentation package upload to me doesn't meet the requirements for a
FFe upload". (I assume that by FFe you mean a beta freeze exception).

Now in this email you're saying the precise opposite. I give up! For
what it's worth, you were right the first time, a documentation upload
doesn't justify an upload during beta freeze.

>> I think you actually did intend your proposal to be that string freeze
>> should be prior to the Beta Freeze, but I still disagree for the
>> reasons set out in my previous emails.
>
> I don't think I did, but honestly that isn't a bad idea either. One less week.
> The only reason I see that mattering is that it is tough to get people to help
> and since Dapper I have noticed that documentation work seems to always start
> around the month of the freeze. I think the one extra week argument isn't
> something to really stand on, because to me it sounds like a fix to another
> problem, which is the lack of documentation writing from the get go.

The argument you're making here I think is that having a recent upload
of the documentation in the beta release is useful because people will
review the documents and file bugs.

I agree that having regular and recent uploads of the documentation in
the various Ubuntu pre-releases is helpful. But having a "final"
release of the documentation in the Beta Release doesn't help, because
either on the present schedule or on your proposed schedule (and I'm
still unclear what the proposal is), no changes to the documentation
can be made after the string freeze, save for exceptional
circumstances [1].

[1] https://wiki.ubuntu.com/DocumentationStringFreeze

I'm not saying that an extra week makes a huge difference to our
writing time, I'm just saying that I don't think your justifications
for moving the freeze are logical, hence I'd personally like to keep
the freeze where it is simply to give us the maximum time reasonable
for document writing, in particular given that new features tend to
arrive quite late in the Ubuntu release cycle. A good example is the
announcement of Eucalyptus in the Ubuntu Server Edition[2], which has
been very promptly documented and introduced into the serverguide
document this week.

[2] http://warma.dk/blog/article/97/

Obviously if possible we should try to avoid dropping large new
sections into the documentation in the last couple of weeks before the
string freeze. Ideally these should be focused on bug fixing.

> Now that I look at the Release Schedule a bit
> better, I think String Freeze would have been best for Week 19. Honestly I
> would like to see more time for translations as well. Documentation gets
> months, translations get 3 weeks.

Translations don't get 3 weeks - nowadays translations are opened at
an early stage in the release cycle. Again, if regular uploads of the
*-docs packages are made, then the translators can work on the
majority of the strings as soon as they are uploaded. It is only the
most recently changed strings that have to be translated in the 3
weeks after the documentation string freeze. (And of course strings
which were translated in a previous release remain translated in
future releases).

That is another reason why if possible large changes should be made as
early as possible in the release cycle, with the last couple of weeks
before the string freeze being focused on bug fixing.

> I have been looking at the documentation
> translations, and you know what, there are far fewer completions these days
> then were a couple of years back (especially in Kubuntu docs).

If this is true (I haven't done a comparison), I would suggest that
this is a result of (a) a lack of regular uploads, and (b) lack of
communication with the translators, or of course simply a reduced
interest in kubuntu-docs translations on the part of translators.

>> The best approach is to upload a package prior to Beta Freeze and then
>> after the Beta Release, to take into account any new changes
>> introduced prior to the docs string freeze. This is what we have done
>> for ubuntu-docs, and it has been working ok.
>
> And I am fine with that, but this way here we don't get the amount of eyes on
> that we could get.

Well, if you upload a package right before the Beta Freeze, then you
will get those eyes you are talking about on that. All that will
change are those strings changed in the next 7 days, and those will be
included in the next update (if uploaded promptly).

But this is pretty much all theory anyway, because people tracking the
development release won't read the documentation unless specifically
prompted or requested to do so. Which is your next point:

> Sure we can post blog after blog to bring the attention as
> well, but I think having it in a beta announcement is much better than the
> Planet.

I agree that bringing attention to the docs is a good idea, but I
don't see what difference the string freeze makes to putting something
in the beta announcement (if appropriate), blogs or other news
services about new documentation or documentation generally.

-- 
Matthew East
http://www.mdke.org
gnupg pub 1024D/0E6B06FF