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.
To be clear -- I'm *tremendously* grateful to David, Dom, Hub, Martin,
Michael, Tim, and others who've been busting their butts to get the 0.9.x
releases out the door. My goal here is simply to find a way to streamline
the release process and get those folks more help.
It's been a long while since I managed releases for us, and I'm afraid we've
lost more than we realize in the transition. While we no longer have the
luxury of paid staff who can work full-time on issues like this, our users
continue to care about the end result of the release process, regardless of
how we pull it off.
Ideally, people's experience of a new AbiWord release would include all of
the following:
1. They hear about it everywhere.
2. They know what's in it.
3. They can easily grab packages that Just Work.
4. They can easily grab sources that Just Build.
Since AbiWord users come in all shapes and sizes -- and more importantly,
use lots of different platforms and languages -- this is, admittedly, a
tough standard to meet. (For more details on what each of these four
entails, see below.)
Having done most or all of these jobs in the past, I'm painfully aware of
the effort it takes to meet this standard, and I sympathize greatly with the
burden this places on the folks who try to manage the release process. For
one person, no matter how talented, to do *all* of this in less than a few
days would require a level of superhuman effort that we usually try not to
ask for.
Do we have general agreement that these are desirable goals?
If so, then I'd like to propose that we continue the carving up the existing
job of "release manager" into smaller, more manageable roles as follows:
evangelist(s)
- responsible for marketing the release (#1)
- one person oversees the "spin creation"
- could distribute the legwork of notifying everyone, though
writer(s)
- responsible for content (#2)
- make sure we have complete release notes
- refresh all appropriate website content, too
packager(s)
- responsible for creating "enough" clean packages (#3 & #4)
- this could be ad hoc, Sam-style ... upload one package & MD5
- or more systematic ... fix Tinderbox and build farm
tester(s)
- responsible for testing and verifying each package (#3 & #4)
- by definition, this must be someone other than the packager
- this is all manual labor, I'm afraid
- would help to have a minimal checklist, though
release manager
- coordinates all of the above
- proposes a coherent release point (ie, enough features done)
- recruits and oversees other roles
- may choose to fill in on missing roles, or just complain
- officially tags each release candidate in CVS
- most importantly ... *holds* the release until it's *all* ready
Obviously, this approach will only work if enough people are willing to
volunteer for each of these important roles. So long as we rely on one or
two heroes to do this kind of work for us, we can expect only so much.
However, I'm very confident that, given how much AbiWord means to people,
we'll see folks step up to the plate for each one of these more narrowly-
defined jobs, so that whoever acts as release manager can focus on the very
most important job of all:
Maximizing the pride we can take in what we finally release.
Thus, in this kind of scenario, a release process would involve:
- identifying a target date and feature set,
- getting buyin from the people fulfilling each of these roles (by name),
- shining a daily spotlight on what still needs to be done, and
- waiting to flip the "release it" switch until the appropriate time.
How does that sound? Who's ready to volunteer?
Paul
======================================================================
R E L E A S E P R O C E S S T H A T J U S T W O R K S
The experience of a new AbiWord release, from the perspective of an existing
or potential user.
1. They hear about it everywhere.
----------------------------------
It's officially announced on our mailing lists (abisource-announce,
abiword-dev, and abiword-user). It's widely announced on download sites
(freshmeat, download.com, etc.) as well as Linux news sites (LWN, Linux
Today, Slashdot, etc.) as well as other platform-specific hangouts for the
GNOME, Be, QNX, etc. communities. To reach such a diverse userbase is,
"everywhere" is a surprising broad target.
In short, each new AbiWord release should be a big deal for everyone,
because the product's significantly better to use. (In other words, if
there's no such clear improvement, why bother releasing it?)
2. They know what's in it.
---------------------------
In addition to complete release notes (available in the package, on the
website, in the announcements, *and* on the "check versions" page), there's
also a much shorter description which emphasizes a few key improvements that
distinguish this release from the previous one.
Focusing on a specific theme like this helps drive excitement about the
product. Not only does it attract people who've been waiting for AbiWord to
start supporting the feature they need (for example, BiDi), but it also
helps existing users decide whether it's worth their while to upgrade.
3. They can easily grab packages that Just Work.
-------------------------------------------------
In the past, we supported a wide variety of package formats for binaries and
sources, which maximized the number of users who could just grab AbiWord and
start using it productively.
Unfortunately, we've been slipping further and further away from this ideal.
While many of us were frustrated by the pace of Sam's 0.7.x release
process, it *did* have the net effect of making sure that we had "enough"
packages and that they all built and ran cleanly on someone other than the
developer's system. Moreover, with that many "new eyes" looking at the
release candidates, and trying to run them for as little as five minutes,
many blatant fit-and-finish issues can and did get caught *before* the
release.
(Yes, I know that having a functional build farm spitting out working
Tinderbox builds daily on all our supported platforms would help a *lot*
here. If anyone feels they have the skills to help get that back up and
running, please send me mail privately.)
4. They can easily grab sources that Just Build.
-------------------------------------------------
As an Open Source product, the most embarrassing thing we could do would be
to not release the *exact* sources needed to rebuild the binaries we
release.
This should go without saying, because it's so easy to ensure, but IMNSHO
every release we do *must* include, at minimum, the following three source
variants:
./crlf/*.zip (for Win32)
./lf/*.tar.gz (for Unix and BeOS)
./lf/*.zip (for BeOS and Unix)
Moreover, each of those source variants *must* build a working product --
ideally the one we released.
======================================================================
