[sugar] 0.84/9.1 planning.

Erik Garrison erik
Tue Oct 14 19:45:10 EDT 2008


On Tue, Oct 14, 2008 at 06:15:31PM -0400, C. Scott Ananian wrote:
> On Mon, Oct 13, 2008 at 2:46 PM, Ed McNierney <ed at laptop.org> wrote:
> > I would also like to stop calling this "9.1" planning.  We need to plan the
> > development work we need to get done, regardless of whether that work will
> > be able to ship next March.  At a certain point we will have some of this
> > work complete and available for qualification in a March delivery, and we'll
> > ship that as 9.1.  And we'll keep going to qualify and ship more of it in
> > 9.2, and more in 10.1 (or is that 0.1??), etc.
> 
> I disagree.  Part of the focus of the meeting is to present all the
> ideas for future development, and then drive stakes in the ground for
> what's going to be in 9.1.
> 

> ...

> In the past we have divided tasks into "next release" and "future
> release" where the "future" really means "never" because we don't do
> *any* of the work in the "next release" timeframe.  That needs to
> stop.  *Everything* we want in a "future release" must have *some*
> piece we can do now, so that we continue to make progress on our
> long-term goals.
> 

I think this is exactly the kind of issue which Ed's suggestion is aimed
at resolving.  By focusing our development on releases instead of
problems, we tend to classify issues into "next release" and "future
release".  It shouldn't matter what release a given issue will fall
into.  But this is not what occurs in practice.  As release time draws
near everyone is encouraged to drop long-term issues so that a release
date can be met.  And consequently the "future" issues are never
approached.

I agree with Ed in that I feel that focusing on the specific release so
far before we have to pull software together is going to create exactly
the dicotomy between "next" and "future" you note.  I would prefer to
have a general software planning meeting and not a 9.1-specific planning
meeting.

Erik



More information about the Sugar-devel mailing list