Documentation & Translation schedule review

John J. McDonough wb8rcr at
Tue Dec 22 14:13:53 UTC 2009

On Mon, 2009-12-21 at 10:57 -0800, John Poelstra wrote:

> I'm still not clear what our starting point for tomorrow night's meeting 
> is.  Since I haven't seen a response (forgive me if I missed one) I'm 
> assuming we will be using (#b):
> I have already put it on gobby.  Feel free to start editing gobby now.

I had kind of hoped that you would fix the dependencies on your
schedule.  We are still building rpms later than we need them.

> Note, the names of some of the releng milestones (Beta Freeze and Final 
> Freeze) changed to match: 
> What can really help make tomorrow's meeting tremendously faster is to 
> populate the drafted version on gobby in advance with what you think the 
> dates should be to address the concerns you raised at: 
> Then we we can spend most of our time critiquing the draft instead of 
> going line by line which will take a lot more time.

I'm not nearly as concerned with the dates as with the dependencies.
> If you'd like to call out task dependencies, maybe add that as part of 
> the task name in ( ).
> I spent some more time today trying to understand the issues you are 
> raising in the email and 
> but it is not 
> completely clear to me if these are the real dates you want to use or if 
> this was just a "brainstorm."

Again, I'm not nearly as concerned with the dates as with the
dependencies.  I've put some comments in the gobby doc, but it is pretty
hard to follow in that format.

My main concerns are:
  - Build RPM before RelEng needs it, not after
  - Translate before build RPM
  - Write before translate

We seem to have the second two down, but the gobby sked still has us
building RPMs after RelEng needs them.

I do think we need a few days for the beta RPM, and probably the RC RPM.
It might make sense to make an RPM for RelEng's test compose, and leave
say 3 days for that, then make another RPM for the final compose.  That
one we could do in a day.  It only takes a few hours to make an RPM, but
we always seem to run into some sort of issue.  I figure if we deal with
those issues for test compose, we can allow translation to continue and
when we build for final compose we will have dealt with any issues that

We also don't quite understand what our interface with L10N looks like
this go. there are a number of issues we need to work there:

 - Is the new Transifex finally there?
 - If not, does L10N do the POT merging/PO splitting?
 - Do we do a ton of branches like we did for F12?
 - Does L10N make their own htmls as needed?
 - Does L10N do the push to docs.fp.o?


More information about the Fedora-trans-list mailing list