On Sun, May 31, 1998 at 12:55:20AM -0500, David Engel wrote:
> On Sat, May 30, 1998 at 01:04:41AM -0600, Bdale Garbee wrote:
> > 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.
I began this message thinking I was going to be pointing out that things
like "cron" [Important] and "cvs" [Standard] really deserve different
priority levels. But actually having gone through dselect's list of
Important packages, there's really not all that much stuff there. So
here's another "aye", fwiw.
> > 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,
This is slightly different to what 'standard' means at the moment,
I believe -- anything one might reasonably expect to be present on any
normal Unix system.
And it gives me the opportunity to suggest that we should consider moving
things like bug into standard.
[btw, is there any reason anacron is priority extra? It's supposed to be
a normal sort of thing to install on machines that aren't permanently up,
which I suspect isn't quite "unusual requirements"...]
The other thing that's worth considering is how much of this would be
better solved by using a different classifcation scheme.
When, for example, we develop a method for tagging packages as being
appropriate for "Unix workstation", "X Terminal", "Network server",
"ISP" and whatever else, we could also list packages that are "Certified
by the Debian Testing Group". [0]
> > 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 think you are overestimating the ability of many users to recognize
> the subtle distinction between package priorities.
*shrug* I expect there are people who curse RedHat for dodgy packages
uploaded to their contrib directory.
I can't see us getting a final answer here, but being able to say "We
don't have the manpower to test all our packages. We focus on the Required
and Standard packages. If you'd like to help, join the -testing group"
should go most of the way.
> You sort of suggested that the dividing line between core and non-core
> packages probably lies between the current optional and extra
> priorities. Upon further thought, I think it might lie somewhere in
> the middle of optional. Either way, what then would be the harm in
> moving the extra packages to contrib?
Debian's dedicated to providing a free operating system. It's the first
thing our proposed constitution says, even. I think it's nice to keep
the distribution split up into "free", "free, but needs non-free stuff"
and "non-free", without dirtying the water.
[three sorts of user, rearranged, with trimming and extra comments:]
> > The first group wants to always have the latest of everything, regardless
> > of testing level or absolute stability.
...who don't require any special testing, but do want daily updates or
similar.
> > We think the [second] 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.
...who don't want anything common to break [like grep only working on
stdin, for example], and thus need a buffer of the first sort of users
between them and the latest release. They'd like irregular updates, so
that packages wouldn't get more than a month out of date, say.
> > The [third] 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.
...who don't really want anything to break that could have been fixed,
and who don't really want updates more than a few times a year [once
every six, four or three months, say].
I think all are fairly reasonable uses of Debian GNU/Linux, and I'm
inclined to thinking that they cover enough of the Linux community,
and are distinct enough to be worth a different categorisation each.
Since it seems to be the current trend, I'm going to throw in YA
suggestion on how to rework the distribution process. I trust Guy,
Brian et al will take the bits of these that have a chance of working,
put them together, and we'll all live happily ever after.
What I'm about to suggest is based somewhat on the philosophy of ensuring
we're always just a step away from being ready to release; rather than
having huge amounts of pointless administrative style junk like we're
stuck with now. Ironically, it's an idea I first heard about from a
Microsoft book.
Anyway, I suspect that a slight restructuring of what we consider
"stable", "frozen", and "unstable" would work reasonably well. Basically,
having "stable" be exactly what it is now -- tested as well as we can
manage, and dedicated to being reliable rather than particularly up to
date; "unstable" more or less the same, the distribution you add new
stuff to and do whatever to.
But rather than having "unstable" be the working copy of the next release,
I was thinking of giving that title to "frozen", leaving "unstable"
more along the lines of the release after that.
Packages could only be moved to "frozen" after being static in "unstable"
for a week or so, and with no release-critical bugs filed against them
and with the release manager / the testing groups permission.
The testing group then has the entire three, four or six month release
cycle to spend testing packages, installs, and whatever else before
releasing, and important or interesting updates can be easily added to
the distribution. Meanwhile, CDs can be burnt from the frozen release
with the knowledge that while it won't be perfect, it'll be pretty damn
good nevertheless.
There'd probably be a fair amount of redundancy in the work the testers
would have to do [``There's a new version of foo! You *gotta* include
this! It's so cool!'' ``But we've already spent *aeons* testing the old
version!!''], but with some automated assistance, and the extra time they
should be able to afford, I don't think this would be too huge a problem.
It'd probably be a good idea to get weekly or fortnightly CD images of
`frozen' made available on ftp.debian.org or similar, too.
Transitional releases are something we probably ought to start
expecting, too. From what I've read, *every* release of Debian has been a
transitional release [a.out -> ELF, libc5 -> glibc, FSSTND -> FHS, ...],
and I think the above would work reasonably well for that. We could,
for example, make releases with a process something like:
bo-released: stable = libc5, unstable = libc5 + misc updates
Then we discover that getting libc6 bootdisks is difficult, say, so we
can't move to libc6 yet in its entirety, but there's some neat libc5
enhancements to various programs, so those are added to frozen, while
people work on bootdisks in unstable.
stable = libc5, frozen = libc5+misc updates, unstable = libc6 + libc5
Then we decide, yup, frozen's stable enough, so let's make a point
release, so we relink stable to frozen, and release 1.3.1, say.
Then we finally get bootdisks compiled in unstable, and a fair few of
our packages have gone libc6, so we move libc6 into frozen, and start
testing it.
stable = libc5+misc u/dates, frozen = libc6/libc5, unstable = libc6/libc5
Then we decide it's time to go on a libc6 recompiling spree, and end up
with all of unstable recompiled to libc6, say, just when the testing group
get frozen tested. [and you *know* something like that's going to happen]
So the testing group get fed up and decide to release what they've done so
far as pre2.0 or 1.99, or just plain 2.0, or whatever, and we end up with:
stable = libc6/libc5, frozen = libc6, unstable = libc6, FSSTND/FHS
And we keep on moving on.
As is probably obvious, I tend to think it's probably more feasible to
move the "base" packages over to {libc6,FHS,the new debian-doc standard,
whatever} and then move everything else over in the next release cycle.
Cheers,
aj
[0] I'm assuming that we'd have a file something like:
Category: Unix Workstation
Packages: cron | anacron, mail-transport-agent,
mail-reader, ...
Category: X Terminal
Packages: xbase, xserver, ...
In which case adding:
Category: Certified by the Debian Testing Group
Packages: perl, perl-base, cron, ...
Would be quite simple.
I'm tempted to go further and suggest that packages be grouped
in a manner similar to:
Category: Unix Workstation
Required: binutils, textutils, vi, sysvinit, ...
Standard: emacs, tex, rcs, make
Optional: ...
--
Anthony Towns <aj@humbug.org.au> <http://azure.humbug.org.au/~aj/>
I don't speak for anyone save myself. PGP encrypted mail preferred.
``It's not a vision, or a fear. It's just a thought.''
Attachment:
pgpZ1Ib3VVbj4.pgp
Description: PGP signature