Documentation & Translation schedule review
John J. McDonough
wb8rcr at arrl.net
Fri Dec 11 22:55:02 UTC 2009
Looking at it with my Release Notes blinders on, I think we need to
first focus on the major tasks, AND THEIR RELATIONSHIPS. I'm sort of
ignoring docs.fp.o at this point because that happens almost
automatically as a result of having the RPM.
Starting from the end ...
We need to have the RPM built BEFORE the RC Compose. Somehow we managed
to miss this little detail for F12. There are always hiccups so I think
we should leave 3 days for this. We *might* end up with another RPM for
the "Bug Complete" compose, but since we will have addressed the issues
already, we can probably get by with a day for that.
Backing up from the RC RPM, it looks as if we don't gain a lot by trying
to get all the translation done for beta like we did for F12. The time
for GA is about the same as the time for Beta. So let's assume we have
10 days for translation (which must be finished before we make the RPM),
and another 10 days for post-beta edits, that brings us back about to
the Beta compose, so basically, it is the maximum amount of time we
So the basics are:
- We need to have the RPM **before** RelEng's compose
- We need the translation before the RPM
- We need the text before we can translate it
The only difference between Beta and GA is that for Beta we probably
should take an extra few days for unclaimed beats.
Alpha is kind of a minor event since we don't translate it, and in the
past we haven't made an RPM (although I think we should).
Take a look at
there are lots of other things we need to do for Release Notes, but
these are the things that essentially set the schedule. Unfortunately,
the html export doesn't show the dependencies, which are the main thing.
But all of the other tasks are mostly noise. It is this business of
write, translate, make the RPM that sets the schedule, and we need to
give Jesse the RPM before he composes, so RelEng's composes are major
milestones as far as we are concerned.
Also, there is an assumption here that the new Transifex is in place.
We have also had discussions about sending POTs much more frequently.
The way we have been handling it L10N gets the MINIMUM amount of time to
do the translations. Often we have plenty of changes backed up before
we can reveal them to L10N. This doesn't seem like the best plan. We
have an accounting problem trying to keep all the partial and un-done
translations straight, and L10N is as rushed as possible.
On Fri, 2009-12-11 at 12:22 -0800, John Poelstra wrote:
> In anticipation of the meeting suggested by Sparks on logistics list,
> I've created a text version of the schedule that should work well for
> customizing or using in gobby.
> This version is a combination of:
> 1) key milestones for the release as a whole (to provide context)
> 2) Documentation tasks
> 3) Translation tasks
> The most helpful feedback you can give me (at the meeting or elsewhere)
> is to provide corrections, additions, or deletions based on the version
> I've created. It does not help me if you create your own version from
> scratch and refer to it because then I have to start all over which is a
> big investment of time. A patch or diff against the original file works
More information about the Fedora-trans-list