Re: so what? Re: Debian development modem
In article <[🔎] 19980529230129.A4537@elo> you wrote:
: If I understood another message correctly, the test team has
: only recently finished checking out the required and important
: packages, now hopes to check out all of the standard packages and
: probably won't get to the optional and extra packages at all.
If we were to beef up the documentation of what the priorities on packages
meant, and made it clear that there was a descending scale of promised quality
for priorities farther from 'required', I think we could take care of most of
the problems you're identifying. Yes, there will always be some user unhappy
about a bug, or a package that goes orphaned... but dwelling on that may be
counter-productive.
I had an interesting chat with one of my cohorts at work today about this
topic. We spent some time thinking about the various Debian users we know,
and tried to characterize what they want from the distribution. What we came
up with was the notion that it splits three ways.
The first group wants to always have the latest of everything, regardless of
testing level or absolute stability. This includes a fair number of the
Debian developers, and some of our more wild-eyed friends, but isn't the
mainstream. This community can be reasonably assumed to be net-connected,
and probably cares about CD'd only when they're doing a cold install.
The second group is CD-focussed. They are either folks who aren't on the
net with lots of bandwidth, or who are using Debian to provide the platform
for other work, and don't want to be "bothered" by constant change. For these
folks, a fresh CD every half-year or year is good, and it's important that
the bits they get be as robust and bug-free as possible. Once they install
a package, they're making a long-term committment to that package revision.
So far, nothing new.
We think the third group represents the primary target market for a
distribution like Debian. This group has good net access, wants to stay
reasonably current, but can't tolerate dealing with the worst 10% or so of
the package churn that happens in a bleeding-edge "unstable" tree. They would
prefer not to bump into any real problems, but they're willing to stumble once
in a while if that's the price of keeping up with security patches, new
development tool releases, and the like. This group might be characterized
by those who are currently running 'hamm' on production servers, as we do at
work.
The insight we had was that for this third group, formal testing is icing on
the cake, and not really required. If we were to implement a "package pool
with symlink trees" approach such as I described yesterday, we might envision
training our automation not only to routinely build a symlink tree of the
latest versions of each package for the first group, but also to build a
"stable but unreleased" tree for this third group. The key concept is that
if a package version has been released for some period of time (a week, a
month, not sure how long makes sense) without being retracted or superceded,
then it is, by definition, "stable"... even though it's absolute quality is
still an unknown. Put another way, if there is active development underway on
a package such that new revisions are showing up every few hours or days, this
third group of folks doesn't want to upgrade or install the package until the
churn rate slows down... and that's a relatively easy idea to automate.
So, group one wants nothing between them and the developer's uploads, group
two wants a human testing team to have reviewed and approved each package that
is on their CD, and group three doesn't want to wait for a human testing team,
but wants to distance themselves a touch from the bleeding edge.
While we were talking, another thing that was really clear to us was that
'standard' and 'important' should be merged, leaving the name 'standard' for
the combined priority. That would leave 'required' as the set of packages
that are part of the base install, 'standard' as all the stuff that one might
reasonably expect to be present on any normal Debian system, 'optional' as the
place where most packages live, and 'extra' for the kinds of things that get
shoved out there now... dangerous toys, etc. Once we get past this
constitution thingy being ratified, I intend to propose this officially.
More food for thought for slink and on...
Bdale
--
To UNSUBSCRIBE, email to debian-devel-request@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
Reply to: