Public SourceMage Discussion List

[Andrew <afrayedknot AT thefrayedknot.armory.com>]

On Fri, Jan 05, 2007 at 09:52:44AM +0000, Juuso Alasuutari wrote:
> On Friday 05 January 2007 09:23, Thomas Orgis wrote:
> <snip>
> > Then, let's get that stable-0.6 out and start the next cycle with a
> > real schedule that is fulfilled (a month, two?).
> 
> So what would the optimal release interval be for us?

I think the faster the better personally. I want to shoot for about two
weeks. I think thats do-able. If it isnt then we're taking too
many spells. Shorter cycles are better for two main reasons:

1) less time for test to change. This means fewer new bugs to fight per
release, that lowers the overall complexity of the release. I think the
complexity grows more than linearly with the number of bugs, so sooner is
less work than later, even if the number of bugs introduced is the same.

2) The cycle length defines the maximum amount of time it takes for
non-critical fixes get to stable (its bounded by 1 and 2 cycles). Inherent
in the notion of a fixed stable is the consequence that bugs will be
fixed in test, but not stable. I think all bugs fall along some scale of
how long people are willing to wait for the fix to get in stable. If
the cycle time exceeds this threshold then typically an integration is
requested. So, the number of integration requests is directly proportional
to the length of the release cycle. Shorter release cycles mean more
"automatic" integrations.

<aside>
As time goes on I remember more details from the past. Previously we
figured there would be a roughly constant list of supported spells
(top 25% from ledger) and as the spells stablized the release cycle
time would naturally get shorter. Each cycle would be shorter than the
previous, and therefore have less code-churn, and therefore fewer bugs.
Then eventually the cycle would reach some suitably short time-delta, and we
could start adding spells. In other words, to start the process hold the
list of spells constant and gradually decrease the cycle. The above
approach instead holds the length of the cycle time constant and gradually
increases the number of spells. Maybe that approach will work better for us.
</aside>


> 
> We should agree on a time table and really stick to it. We should know in 
> advance when the next release will happen, and the one after that, and when 
> the second release in 2009 happens. I don't mean automatically generating a 
> tarball even if a major fix is in mid-commit, but you get the idea. I don't 
> believe in forcing people, but having a set deadline is different. At least 
> for me it's a good motivator, I don't know how others feel.

I think we should try a couple cycles, tenatively w/ the 2 week time. We
might not hit 2 weeks the first few cycles while we work the bugs out. So
I dont want to set a formal time-table to stick to just yet. After a few
cycles though, we'll have a better idea of how much work we can get done
per cycle.

Another idea I just had is that maybe the organizer of the release should
rotate amongst the leads. The organizers role being to make sure things
get done. They dont for example have to actually create/sign/upload
the tarballs, but they should make sure that it happens in a timely
manner. I'll do this one of course. I think there are advantages in
rotating the responsibility, more people know directly how things ought to
work, no one gets burned out, and its in the spirit of the "lead-team"
idea.

-Andrew



> _______________________________________________
> SM-Discuss mailing list
> SM-Discuss AT lists.ibiblio.org
> http://lists.ibiblio.org/mailman/listinfo/sm-discuss


-- 
_________________________________________________________________________
| Andrew D. Stitt  | acedit at armory.com    | astitt at sourcemage.org | 
| irc: afrayedknot | Sorcery Team Lead       |      ftp://t.armory.com/ |
| 1024D/D39B096C   | 76E4 728A 04EE 62B2 A09A 96D7 4D9E 239B D39B 096C  |
-------------------------------------------------------------------------