Fedora 15 Schedule

[Dave Jones]

On Mon, Nov 29, 2010 at 03:01:59PM -0800, John Poelstra wrote:
 > Disclaimer: I'm pursuing this issue because Jesse told me the kernel 
 > team wanted to be better integrated into the Fedora development 
 > schedule.  I'm getting the impression, however, that may not be want you 
 > want.  To be clear, I'm not trying to force a schedule on the kernel 
 > team.  Instead I want to help create something that will useful to 
 > Fedora and to you.  If neither of these objectives can be met, then my 
 > work here is done. :)  If there is a better way to approach and go it, 
 > please let me know.

The discussion I had with Jesse about this a while ago was more related to
things like the readyness meetings should really have someone from the
kernel team representing. 

 > > So we can say "F15 is going to be 2.6.38" now, and that's about as
 > > best a guess we can do. .39 is going to be way after GA, and .37
 > > will be 'stale' by the time GA occurs.   The exact timing of .38 however
 > > is tied to factors we don't control.  Guessing the release date is
 > > pretty pointless.
 > >
 > 
 > I am not suggesting or saying we guess at an upstream kernel version or 
 > that we can guarantee an upstream release date.  I am asking, when 
 > during the Fedora release process, does *Fedora* decide which upstream 
 > version of the kernel it wants to include in it's upcoming release.  In 
 > other words, at what point in the Fedora release cycle do we stop taking 
 > the "latest from upstream" and lock onto a version that Fedora will GA 
 > with?

we can usually make a guesstimate as soon as we're done with the previous release.
I don't think we've ever gotten it wrong, and had to drop back to the previous version.
One time we did cut things a little fine, but we ended up slipping the release
anyway, so it worked out. iirc that time, we were trying to be too aggressive
and squeeze 3 rebases in because upstream did a shorter release.
Two seems to be the limit for 6 month schedules.

 > > historically, we've just kept building new candidates for as long
 > > as we have release critical bugs.  I think that criteria is more useful
 > > to meet than a date.  There's always 'one more bug' of course, but
 > > the acceptance criteria for blockers near the end is pretty tight.
 > 
 > In Fedora 14, Dave Lehman from the anaconda team requested specific 
 > dates to reminded that a new installer build was needed, typically a few 
 > days before important composes.  Would a similar reminder for the kernel 
 > be helpful to make sure that important patches get testing coverage or 
 > address blocker bugs?

Sure.

 > >   >  3) What dates and tasks are important to the kernel team to remember AND
 > >   >  complete in order to have a smooth Alpha, Beta, and Final release cycle?
 > >   >
 > >   >  4) What are important tasks that have been overlooked in the past that
 > >   >  if tracked (and set to your list as a reminder) would have helped the
 > >   >  kernel to play nicer with the rest of the Fedora release cycle?
 > >
 > > Disabling debug-by-default is the only real date-driven thing we do.
 > > Everything else is driven either by upstream release schedules, or
 > > by the QA team deciding if something is blocker worthy or not.
 > >
 > 
 > Which date should that happen on?
 
We usually leave debug on all the way up until the final beta, then turn it
off for final.  Again, there have been exceptions. If we're seeing corruption
bugs for eg, we've left it on longer until they've been sorted.

	Dave