Releases in 3 months

[Scott Kitterman]

On Monday, July 15, 2013 02:48:01 PM Albert Astals Cid wrote:
> El Diumenge, 14 de juliol de 2013, a les 04:19:52, Inge Wallin va escriure:
> > I think keeping 6 months is a good
> > figure to ensure both reasonable turn-around *and* actual bugfixes of
> > versions being used in the real world.
> 
> It may be a reasonable turn-around for some users, but it is also not
> defenitely reasonable for some developers.
> 
> Real data:
>  October 25, 2012: KDE SC 4.10 Soft Feature Freeze
>  August 14, 2013: KDE SC 4.11 Release
> 
> This means that if a "new" developer suggest a new feature (with half
> finished code) just after the soft-freeze has kicked in, when told he has
> to wait almost 10 months to see his feature released, he will probably
> walks away since he thinks "that's too long, i might be dead in 10 months".
> And we just lost a potential developer, and to be honest, users can be
> sometimes awesome, but I'll take a developer over a user any time, since
> the developer will help us getting more users ;-)
> 
> We need to find a way to make it easier to hook-in this kind of developers,
> 10 months is just too much.

Picking this apart a bit more, this 10 months represents:

FF -> Release -> Development -> FF -> Release

So time between last opportunity to land an unplanned feature is two times the 
time from soft feature freeze to release plus one times the development window 
in the next cycle.  Based on the 4.11 schedule, that looks like:

Wednesday, February 6, 2013: KDE SC 4.10 Release
Wednesday, May 22, 2013: KDE SC 4.11 Soft Feature Freeze
Wednesday, August 14, 2013: KDE SC 4.11 Release

FF -> Release = 15 weeks
Development window = 12 weeks

15 x 2 + 12 = 42 weeks (or ~  your ten months)

30 of the 42 weeks are spent in some kind of freeze state.  Without process 
changes to get from "feature complete" to "released" there's no way to get to 
a three month cycle.  

Rather than aim for some arbitrary cycle length when you are discussing it, I 
think that it would be useful to look ways to reduce the time from FF to 
release without reducing code quality at release time.  Once there's a 
reasonable approach to do that, then, based on how long that period needs to 
be, it'll be pretty clear how long the release cycle should be.

Every week that can be taken out of the FF to release process actually gets 
the time when the hypothetical new contributor can see their contribution in a 
release reduced by two weeks.

The other nice thing about focusing on process improvements around FF to 
release is that they can be done/demonstrated to work without simultaneously 
shortening the release cycle.  I think one step at a time would be a safer 
approach for the project.

Scott K