Skip to Content.
Sympa Menu

sm-discuss - Re: [SM-Discuss] Let's make Source Mage not suck!

sm-discuss AT lists.ibiblio.org

Subject: Public SourceMage Discussion List

List archive

Chronological Thread  
  • From: Andrew Stitt <afrayedknot AT thefrayedknot.armory.com>
  • To: SM-Discuss <sm-discuss AT lists.ibiblio.org>
  • Subject: Re: [SM-Discuss] Let's make Source Mage not suck!
  • Date: Fri, 5 Jan 2007 17:55:50 -0800

On Fri, Jan 05, 2007 at 01:51:10PM -0800, Eric Sandall wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA512
>
> Andrew wrote:
> > 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
>
> I think a two weak window should work for a limited number of spells.
> Shall we start this timer this Sunday (January 7, 2007) for the current
> stable-rc-0.6/stable-0.4 and in two weeks from then have a new
> stable-rc-0.7 from test and a new stable-rc-0.5 from stable-rc-0.6?
>

Im kind of confused by all those numbers :-) But basically, i think the
stable-rc and stable numbers need to be synchronized. So, if the current
stable-rc is 0.6, we'll release it in 2 weeks as stable 0.6. Then start
stable-rc 0.7, which we'll release as stable 0.7 2 weeks later. So we
skipped stable 0.5 altogether because we didnt release stable-rc 0.5.

We can start this sunday, the 7th, and thus release on the 21st. However,
it looks like I'm moving on the 13th (my other choice is the ~20th, which
is worse). My connectivity might be less than ideal that first week. I'll
do what I can to get things back up in time to bring the release to a
close. In the meantime, I'll try to get things as organized as possible
before then, but someone may have to "pinch hit" for me. :-/

-Andrew

--
_________________________________________________________________________
| 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 |
-------------------------------------------------------------------------




Archive powered by MHonArc 2.6.24.

Top of Page