Subject: Re: towards a release process that Just Works
From: Dom Lachowicz (dominicl@seas.upenn.edu)
Date: Thu Aug 16 2001 - 14:24:36 CDT
Quoting Paul Rohr <paul@abisource.com>:
> At 11:40 AM 8/16/01 -0400, Dom Lachowicz wrote:
> >This sort of thing *really* needs to stop happening. We *need* to
> release a
> >0.9.3 ASAP with HTML export bugfixes and without the MSVC msvcrt.dll
> dependency.
>
> I'd actually like to go one step further here, and assert that the
> "rapid
> release" process we've been using for the 0.9.x series so far does *not*
>
> Just Work.
While I'm here with Paul on this one, I'd just like to chime in with my
thoughts on the subject:
As at least Paul, Hub, Martin, and I know, releasing software to the public can
be a tedious time and resource-consuming job. The "normal" Open Source way of
releasing a product is to post a .tgz somewhere and maybe binaries if they feel
like it.
Our problems are multiplied by several factors, and this following list is by
no means exhaustive:
1) Sheer user base
2) Number of platforms
2.a) This includes binaries
2.b) This includes different packaging formats on these platforms (DEB,
RPM, ...)
2.c) This also includes different architectures, where appropriate (PPC,
IA32, ...)
2.d) This includes sources shipped in both .zip and .tgz with the appropriate
line-endings
3) Build options
3.a) Pspell vs. Ispell
3.b) Gnome vs. GTK+
3.c) International Dictionaries
3.d) BiDi
3.e) Libxml2 vs. Expat
Now, it is painfully clear to me that we don't really want to stop supporting
any of these options (for example, running on Win32 and Linux is a rallying
point, not a thorn in our side) - choice, competition, and flexibility tend to
be good in the long-haul, provided that they are appropriately handled. I'd say
that at least Pspell vs. Ispell and Libxml2 vs. Expat "issues" are handled well
right now because we have an appropriate interface abstraction which allows the
programmer not to deal with any of these components directly. Things "just
work" from a programmatic standpoint (SpellManager class returns SpellChecker
instances, inheritance from the IE_Imp_XML baseclass, ...).
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.
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. 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'."
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.
Having a release manager and coordinators and all of those other jobs that Paul
mentioned would be great. Right now, we don't have that, and people to fill
those kinds of jobs are traditionally hard to find. 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.
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. 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).
I'm not proposing any answers or drawing any conclusions here. But these are
issues that deserve to be addressed nonetheless.
Dom
/feel free to discuss/refute
This archive was generated by hypermail 2b25 : Thu Aug 16 2001 - 14:24:40 CDT