Subject: Re: towards a release process that Just Works
From: Tim LaDuca (tjl@141.com)
Date: Thu Aug 16 2001 - 16:06:17 CDT
I volunteer to do win32 builds, and any Linux-i386 builds. That
does not mean I know how to do all possible Linux-i386
builds/configurations. But am willing to do them/fix them as long
as someone gets me started. E.g. I can do Gnome and GTK *.tgz and
RPM's(provided the proper spec file), but haven't figured out
Pspell yet, neither do I know about libxml vs. expat etc. Barring
my computer going up in smoke, I don't see anything barring me
from this potential commitment in the near future(except perhaps
my own stupidity ;-) ). And of course there is a limit to the
number of builds I'll have time to do.
Cheers,
tim
---------- Original Message ----------------------------------
From: Dom Lachowicz <dominicl@seas.upenn.edu>
Date: Thu, 16 Aug 2001 15:24:36 -0400 (EDT)
>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 - 16:05:37 CDT