On Wed, Sep 14, 2011 at 12:26 PM, Ken Conley wrote: > I'm open to suggestions on this one.  For earlier releases, we've had > up to 3 release dates to stagger in changes; for Electric we had just > one freeze date.   The overall system is now much more stable and our > continuous integration systems are much better, such that it is > possible to get 'fresher' software into the final release.  That said, > the Electric single freeze made for a fairly chaotic period and felt > more like a paper deadline with everyone releasing on the final date. I noticed that, too. > My strawman proposal for this round (thanks Troy for the 'slushy' term): > > January 15: Slushy Freeze - APIs with dependencies frozen > February 15: Final Freeze - packaging complete, all APIs frozen > March 15: Fuerte Release +1 January 15 is a Sunday (if anyone cares). > Basically, if your stack is a leaf or has few dependencies, then your > freeze is 1 month prior to release.  If your stack has dependencies, > the stuff that is depended on freezes 2 months prior to release. > Drivers generally fall into the few dependencies category, unless you > are planning on (for example) changing the camera topics. With apologies to Troy, I dislike "Slushy" because some might interpret it as "not really frozen". That is not the intent, but terminology does matter. As you explained, the real difference is a matter of dependencies. Unfortunately, I don't have any really good suggestions. Perhaps just call them "Primary" and "Secondary" freezes. > On a related note, I would like to make unstable more 'unstable' this > time around.  During Electric, unstable was actually incredibly > stable, which slowed updates to lower-level software, and the feedback > we've gotten is very few people are actually using unstable.  In order > to help lower-level stacks develop more quickly (i.e. the stuff I work > on), I would like to let unstable be unstable for the next two months. >  After that, we would try to re-stabilizing unstable so that people > can dogfood new features. +1 Unstable becomes most important between the first freeze date and the release. That is when dependent stacks can profitably test with the new interfaces. --  joq