On Mon, Sep 13, 1999 at 11:55:36AM +0200, Jens Ritter wrote:
> There have been various proposals to speed up the release cycle.
Talk's cheap. OTOH, without the talk, it's sometimes hard to work out
what code we'd need.
See http://www.debian.org/~ajt/ for my (and others) two cents, fwiw.
> Maybe something like this could work:
> We could have a frozen branch in the archive all the time.
I like this idea too. But it's much easier said than done. In particular,
we need some working space (not too much trouble), and we need some one to
maintain it, or we need it to be heavily automated. I prefer the latter.
> A package can only get there, if
...it meets all its dependencies, and doesn't make any of the packages
already in there uninstallable. This is important for things like the
Perl upgrade, kind-of [0]. So, some code that, given:
a Packages file that's all in sync currently
and
a list of new .debs that could be installed, probably in the
same format
will say which of the the new .debs can be installed (concurrently) without
making any packages uninstallable.
I've had a brief look at how this might be done, but couldn't work it out.
I imagine using either libapt-pkg-dev or pkgorder would make it fairly
easy, but...
> A package can only get there, if
...it's BugFree(tm). Or at least, there aren't any hugely horrendous and
obvious release critical bugs. The best way I've heard of managing this
is to keep packages in unstable for a week or so, and after the week's up
compare notes with the BTS to see if there are any RC bugs open.
This shouldn't be all that problematic, actually, in either the cheap
and hacky short term, or the glorious and elegant long term. This is
where I'm trying to do my ObContribution atm.
> A package can only get there, if
...it compiles on all architectures (that are being released, at any
rate). It seems reasonable that in the week the package is sitting
in unstable, the autobuilders ought to be able to upload versions for
their architecture in that week. If it doesn't compile, well that's a
RC bug anyway.
> A package can only get there, if
...the maintainer wants it to. Some packages uploaded to unstable are
just development snapshots, and shouldn't be released. ATM, we let people
say "No! Don't put this in frozen" at the time of the freeze if that's
a problem. Some similar (more automated) method for this would be nice.
Possibly just filing a RC bug would do (and would an encourage an
explanation if someone else out there wants to actually get the package
released).
Anyway. Here's what I think we could do to get this happening *right now*.
First, we need somewhere where we can experiment. Plenty of free disk
space, plenty of free memory, running unstable, an mirror of unstable,
and accounts for everyone who's interested.
Next, we need to mirror *something* into a prerelease directory. No
symlinks to save space or anything, just a straight out simple
mirror. Ideally, not hard links either.
Next, we need some simple automated checks on the status of prerelease.
Things like:
* whether bootdisks work
* whether CD images can be made
* that all dependencies can be satisfied
In the future, a list of RC bugs against prerelease would be nice too
(since, considering dpkg, there'll be *some*, and all we really want
to ensure is that that number usually goes down, not that there aren't
any left). But the BTS can't tell the difference between prerelease
and unstable yet, so...
The reason I said "something" instead of unstable above, is because
atm automated checks to see if boot-floppies compile would fail. That's
bad --- none of the tests against prerelease should *ever* fail. So it
might be better to mirror stable to start with, and gradually add all
the packages we've been working on in unstable as boot-floppies develops.
Next, we need to automate moving stuff from unstable. We need to find
maximal subsets of stuff that can be moved across without invalidating
any of the aforementioned tests, and that only moves packages that are
meant to be moved. This can be done by hand for a while, but we *really*
need an automated way of doing it all.
Finally, we need to get all of this in a fit state to put into Debian
proper --- making sure we don't accidently double the load on mirrors
[1], that moving stuff to prerelease doesn't kill dinstall, that the
BTS can cope, whatever.
Anyway. How about we actually try to get this done?
Who's got time to volunteer for updating prerelease? Getting boot-floppies
up to scratch so we can start moving packages without breaking prerelease
entirely? Writing automated tests? Writing stuff to automatically
move stuff?
Cheers,
aj
[0] Kind of, because the perl upgrade didn't actually make things
uninstallable. It introduced lots of unnecessary conflicts, though:
you could only install foo with perl5.*.deb, and you could only
install bar with perl.deb, which conflicts with perl5.*.deb. In the
long term, this would need to be dealt with too.
I suspect something like:
Since perl5.004.deb conflicts and replaces perl.deb, installing
perl5.004.deb into the archive means removing perl.deb from the
archive. Removing perl.deb from the archive makes such-n-such
uninstallable. Thus perl5.004 won't be installed just yet.
[1] This is what the package-pools idea is all about. It's not really
all that important in the grand scheme of things.
--
Anthony Towns <aj@humbug.org.au> <http://azure.humbug.org.au/~aj/>
I don't speak for anyone save myself. PGP encrypted mail preferred.
``The thing is: trying to be too generic is EVIL. It's stupid, it
results in slower code, and it results in more bugs.''
-- Linus Torvalds
Attachment:
pgp2WL0QlbnSK.pgp
Description: PGP signature