[ros-users] Developers: ROS Fuerte Planning SIGs

[Jack O'Quin]

On Wed, Sep 14, 2011 at 12:26 PM, Ken Conley <kwc at willowgarage.com> 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