Subject: "must have" packages
From: Paul Rohr (paul@abisource.com)
Date: Fri Aug 24 2001 - 16:28:10 CDT
At 02:08 PM 8/24/01 -0700, Paul Rohr wrote:
>At 03:24 PM 8/16/01 -0400, Dom Lachowicz wrote:
>>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.
>
>Would anyone like to propose what our current set should be?
To get the ball rolling, I'll go ahead and take a whack at this. The
following proposal may be a bit controversial, but I think it's more-or-less
on the money, and it should *certainly* spark a discussion.
(( If you hate some part of this, fine, but bonus points go to anyone who
puts in the thought required to come up with a more coherent proposal. ))
Note that I'm only focusing on the packaging level, because that determines
which users can easily download a binary package that Just Works for them.
To be blunt:
Very few users care about releases that they can't, uh, use.
Once we've settled what those critical packages are, we can discuss
particular feature/option variants.
OK. Here goes...
level one: must have
---------------------
Judging from the user numbers on SourceForge, a minimum set would include:
- the three source variants in my original message
- Win32
That alone wouldn't make us any friends, but it *would* cover well over half
our current userbase.
ASSERT: These are "must have" packages for any future release. Period.
level two: really should have
------------------------------
Continuing down the download stats, you get into a stew of Unix permutations
I don't even pretend to understand, but as best I can tell from the ever-
shifting filenames:
GTK > GNOME
RPM > tar.gz > deb
i386 > PPC
en > intl
It'd be nice to minimize that complexity as much as possible, and perhaps we
could get it down as far as two configurations of required libraries:
latest-and-greatest (RH 7.x, RPM, GNOME, etc.)
ultra-compatible (RH 6.2, RPM, GTK, etc.)
Then we could repackage one or both variants (of required libraries) in
additional package flavors (.deb, .tar.gz, etc) as appropriate. However,
I'd rather have someone else sort all that out. :-)
ASSERT: We should have as few variants as possible here. Ideally, I'd
think that there would only be two configurations of required libraries
(bleeding-edge GNOME and ultra-compatible GTK), packaged up in as many
flavors as people would like.
level three: nice to have
--------------------------
Finally, continuing down the list it's clear that there's a small, steady
number of loyal users who're quite happy to see binary packages for the
following platforms:
QNX
BeOS/Intel
Linux/PPC
FreeBSD
etc.
During periods of time when these flavors are being actively maintained,
we've released binaries which users have really appreciated having.
ASSERT: We need to explicitly check whether the maintainer of each of these
would like to have their packages included in the next release cycle, and
give them a reasonable amount of lead time to do so.
Our recent practice of as little as 48 hours warning is rarely enough to
ensure that their stuff even builds cleanly, much less ensure that they're
currently in sync enough with other recent work to produce binaries worth
using.
bottom line
-----------
The criterion I'd like to suggest is that any package variant on the
"official" list needs, at minimum:
- a maintainer (someone actively coding for it)
- a packager (not necessarily the maintainer)
- a tester (definitely not the packager)
I'd like to be incredibly hard-assed about this. Starting immediately, I'd
like to start insisting that we won't release any package unless we get
explicit consent from those two or three people.
Thus, the net effect would be as follows. Before we can release, we need to
explicitly confirm that:
- all level one ("must have") packages have met this standard
- all level two ("should have") packages are either in or out
- all level three ("nice to have") packages had fair warning to opt in
OK, so what does everyone think?
Paul
PS: In addition, I'd love to be in a position where we could insist that
the variant also be building daily on Tinderbox. (That's why I'm currently
working to make that happen, too.)
This archive was generated by hypermail 2b25 : Fri Aug 24 2001 - 16:20:36 CDT