[ros-users] Developers: ROS Fuerte Planning SIGs

Jack O'Quin jack.oquin at gmail.com
Wed Sep 14 18:25:24 UTC 2011

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


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.


Unstable becomes most important between the first freeze date and the
release. That is when dependent stacks can profitably test with the
new interfaces.

More information about the ros-users mailing list