Subject: Re: towards a release process that Just Works
From: Paul Rohr (paul@abisource.com)
Date: Fri Aug 24 2001 - 16:08:03 CDT
At 03:24 PM 8/16/01 -0400, Dom Lachowicz wrote:
>However, the sheer multiplicity of our options is enormous when you try to
>build a matrix of just the above features, platforms, and distributions, and
>that matrix is still non-exhaustive.
Ah, combinatorial explosion. Ain't it wunnerful? Not. :-(
>What I propose is that we (for packaging and other purposes) make a list of
>those features, platforms, and options that we find to be critical, and a
"must
>have" for support. This can vary based on platform, distribution, etc... but
>they need to be in writing somewhere.
Very, very well said. Over time, we've had several subsets of this list:
- the SourceGear / Tinderbox set (early 0.7.x)
- the Sam era set (late 0.7.x)
- the ultrasmall 0.9.x subsets
Would anyone like to propose what our current set should be? I hate the
idea of doing yet another release using the old, broken process without an
explicit consensus to do so.
>These configurations must be tested
>and "Just Work." We may need to poll users or conduct some other
requirements
>gathering to make this work the best. In some cases it might be as easy
>as "what you get when you type 'make'."
Agreed. We need to drill down further on this.
>Those points aside, it is difficult and exhausting to do this for every
>release. This is not so much of an issue when we made a release every 1
1/2 - 2
>months. But if we wish to do frequent incremental releases during the 0.9.x
>series, we must *really* evaluate our position here.
Exactly. Part of the reason I started this thread is to question the value
of ultra-frequent releases.
When I look at the number of 0.9.x and 1.0 bugs remaining in Bugzilla, or
when I notice various additional glitches in the current user experience, I
get the general feeling that, even at our current pace, we're more than a
few weeks away from the kind of 1.0 release we've been targetting.
I have a vague sense that some of us wouldn't mind having a series of
near-weekly releases for the next N weeks, but the thought of releasing
0.9.27, say, makes me squirm.
>And until we find people to
>fill those roles, we will have to make a tough decision, which ultimately
>amounts to:
>
>Are Dom's, Martin's, Hub's, ... times better spent coding, designing,
>bugfixing, helping users, ... or do they have a few days where they can
devote
>all of their time going through a worthwile yet tedious and time-consuming
>release process. This is compounded further when we're releasing a new build
>every week and a half.
Bingo.
In the mean time, I'd suggest that it's better to spend the time making the
software better, instead of dumping out brittle binaries more frequently.
>Most other projects don't have this problem since they only do a Source
>Release, which might be our best option at this point in time.
If we're not releasing binaries, why do source releases at that point
either? Releases are primarily for the benefit of people who use our
software. After all, anyone who can work with a source-only release could
always grab the current sources and work from there.
Again, the long-term solution seems to be to get more people involved so
that we can share the work required. In the short term, I'd rather see
fewer releases done well, instead of a lot of skimpy releases.
>The only other
>projects out there with a comparable support/feature/platform matrix to us
tend
>to be larger, heavily-funded projects with paid staffs, QA departments, real
>management heirarchies, ... (which for right now means Mozilla and in the
short-
>term future, Open Office).
Yep. Of course, we could have two kinds of reactions here:
- envy ... boy, they have so many more resources than we do. :-(
- pride ... boy, look how much we manage to accomplish! :-)
Most days, I manage to take the more positive tack.
>I'm not proposing any answers or drawing any conclusions here. But these are
>issues that deserve to be addressed nonetheless.
Thanks. These are definitely important issues, and I've tried to suggest
some answers.
What does everyone else think? Are there better solutions to these
dilemmas? The products we release are a reflection on the hard work of many
many developers on this list, and I really want to hear how people would
prefer to see this handled.
Paul
This archive was generated by hypermail 2b25 : Fri Aug 24 2001 - 16:00:22 CDT