On Sun, May 31, 1998 at 07:17:57PM +1000, Anthony Towns wrote:
> And it gives me the opportunity to suggest that we should consider moving
> things like bug into standard.
YES, this is VERY IMPORTANT if you ask me (and nobody did).
> [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"...]
Prolly because anacron conflicts lots with cron and cron is important. =>
Of course, someone decided sendmail is extra too, and that's the most
standardized daemon in existance for unix in general.
> 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]
That's AFAIK for the installation scripts only.
> *shrug* I expect there are people who curse RedHat for dodgy packages
> uploaded to their contrib directory.
Not so much really I suspect. I think they would tend to blame the
maintainers of the rpms since RedHat goes out of their way to be sure you
know contrib != Redhat.
> 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.
Agreed!
> [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've already agreed unstable takes care of them.
> ...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.
That is certainly a release critical bug. => Generally I figured as
packages didn't have these it was safe to call them "stable". Figuring them
into my idea is easy because the stable tree fits them fine since it would
be updated as packages moving in to it were ready to be called stable.
> > > 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].
These guys would get the 3-6 month stable CD's. Just before these would be
released (couple weeks) you'd freeze stable and fix anything that's
last-minute and make sure all the install scripts work okay.
> 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.
Not many have commented on my ideas much, but those who have commented
liked them. I'm SURE there's something I'm overlooking, but nobody has seen
it and commented yet. So far it seems to address everybody's concerns and
doesn't leave anybody out in the cold (which is a not insignificant ego
boost to someone who by all rights is still a Linux rookie) so I am going to
believe for now that it's genuinely a good and well thought-out idea till
someone points out a major problem with it.
It sure beats just freezing/releasing unstable at fixed intervals.
> 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.
Which is very similar to mine now that I reread it.
> 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.
I would have changed "stable" to "official"--the last official CD release
version. This tree should not have symlinks to anywhere considering that
it's what someone would burn for the current "official version"..
Unstable would exist kinda as it does now. Packages get moved from Incoming
directly here. "testing" would be a better name for it, but "unstable"
should keep people who shouldn't touch it away. It would be like slink is
now, not a full dist. It's a suppliment, not a dist per se.
Frozen would not exist as it does now. However the closest equivalent would
be "stable". The new stable dist would in fact be stable---more so than
hamm. It'd essentially start as a tree of symlinks to official. Then as a
package in unstable is deemed appropriate for stable, it's moved there and
if there's an older package (link or file) it'd be replaced.
Stable would be expected to WORK and not have any major bugs, but stable may
be in-between goals. Ie, it's been possible in hamm since long before I
started using it to have a libc5 and 6 system.. Stable should be kept
backwards compatible with the last dist--enough that it runs (though for
example the FSSTND -> FHS goal may have files in odd places for a bit.
At regular intervals and/or when determined to be "time for a release", any
symlinks in stable are made into files and the whole mess gets no more
updates for a few weeks while the last bits of testing and any pending
install updates are fixed. Then stable becomes official and we start a new
stable symlink tree.
As for project/experimental.... Do we need to mess with this? Other than
maybe the Packages.gz file which makes no sense to me since it seems it
would be MASSIVELY unwise to use it, even if you use packages out of
experimental (apt).. Feel free to correct me if I'm wrong.
This fits all three types of users and gives up to two levels of fallback if
a new version of something in unstable breaks. If it breaks in stable, it's
a problem but can be fixed. By official, nothing should be obviously
broken, we can hope. =>
> 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.
I more or less changed the names to be more descriptive, but that's kinda
what I've been talking about.
> 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.
I was thinking for a low urgency package more like a month. With the
exception of a Linux kernel, people can wait this long I hope.
> 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.
I kinda figured testing as a more ongoing thing. If you use packages in
unstable and find a bug, report it. Simple as that. Testing for stable to
official should not need to be much, we would hope.
> 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.
I thought about this too, see above. =>
> 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.
Just let the CD venders know they can do this with the stable tree..
CheapBytes would with their Debian Hot Off the Press (which isn't a press,
it's a burn, but hey..) We should make a README.stable indicating this is
generally just fine.
> 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
Debian's good with backward compatibility. If we make that a goal for the
stable and unstable trees (backward compatibility with the last release)
then the libc5 -> 6 upgrade would be no biggie. Hamm is backward compatible
with bo as it is if you install altgcc and libc5-altdev. We should follow
that sort of a tradition.
> 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.
As soon as libc6 is deemed stable it can be moved, and if any other libc6
packages were already considered stable they could move in a week or so.
> 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.
Very much like I've been saying.. GMTA! =>
> 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.
Yes, for anything in base or priorities of standard on up there should be a
grace period before upgrading packages dependant on these changes, just in
case. The libc6 issue is a good reason. libc6 may be stable, and
libc6-using packages may be stable, but if you move them all at once you
have a higher chance of breaking SOMETHING which would be bad.
> [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.
No need under my proposed design, which is admittedly similar to yours other
than how packages get moved.
> 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: ...
Nah. Required packages for Debian don't change no matter what application
you have in mind. Standard packages in Debian should be on the system in
most cases, with the exception of when you KNOW you want different. Some
install options like router or such might not use all the standard packages,
but there's no reason to change that.
Optional packages are optional to debian, though they may be required for
some things. Extra should still be toys that may break stuff in other
classifications, etc but then again in some cases that's what you want and
it should be there for some installations. Doesn't change that they're
generally not needed/wanted for most systems.
Priority should remain a Debian system thing, not an application specific
one.
I would suggest that the install scripts should let you choose any of these
in place of showing you apt. It should allow custom (select required and
standard packages and toss you in apt to figure out what in addition you
want) and other (locate a profile listing packages to install, that's not in
the list--useful for installing several machines I'd imagine)
I await people's opinions! =>
Attachment:
pgpql8TH80dZX.pgp
Description: PGP signature