Re: so what? Re: Debian development modem
On Sun, May 31, 1998 at 12:55:20AM -0500, David Engel wrote:
> > 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?
Anthony Towns <aj@azure.humbug.org.au> wrote:
> 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: our current "contrib" classification says something about
the licensing issues, and that's important.
It should be fairly easy for someone to split optional into optional but
recommended and whatever. I don't want to do the split, however, and
I'd really like the description of the split to be clear enough to
avoid several tens of megabytes of discussion on it by next year.
> 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.
I like this idea, and it kind of matches some of what I was trying to
figure out how to express, and it looks like it matches what Bdale
was suggesting with his "pool of packages". Basically, the developers
part of the ftp site is the simple part, the test&release part is
the big complex part -- we already acknowlege this to some degree
(look at our bug tracking system), but we still put an awful lot
of load on the shoulders of the ftp site maintainer.
Furthermore, we have this practice of pulling stuff out of "incoming"
but we don't really take advantage of it.
And, there's this whole thing where many people have observed that
testing is far more parallizable than development.
So what are we doing about it?
Recommended reading (just a rehash of the messages in this
thread that I think are significant):
David Engel's second rehash of the problem: [important]
http://www.debian.org/Lists-Archives/debian-devel-9805/msg01511.html
Buddha Buck's counterpoints:
http://www.debian.org/Lists-Archives/debian-devel-9805/msg01531.html
David Engel's clarifications on a few points:
http://www.debian.org/Lists-Archives/debian-devel-9805/msg01608.html
Guy Maor's quick summary:
http://www.debian.org/Lists-Archives/debian-devel-9805/msg01623.html
Bdale Garbee's ftp site cleanup proposal: [important]
http://www.debian.org/Lists-Archives/debian-devel-9805/msg01632.html
Bdale Garbee's groupings of debian users:
http://www.debian.org/Lists-Archives/debian-devel-9805/msg01721.html
Unfortunately, the message I'm responding to doesn't seem to be up
in the archives, yes. I'd also like to classify it as important.
So I'm going to include the rest of it verbatim.
--
Raul
> 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.''
--
To UNSUBSCRIBE, email to debian-devel-request@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
Reply to: