A reply to lots of mails, all in one. Note that any of this is open for
discussion.
On Mon, Dec 18, 2000 at 09:29:48AM +0100, Adrian Bunk wrote:
> when testing is woody, have you thought of how to resolve problems like
> the following:
> The important security fix is only in the package in unstable but not in
> testing (and the bug report was closed with the upload to unstable).
Note that security fixes can be buggy too: it's not that much better if a
newly uploaded grep package wrecks your system by breaking crucial scripts
than if a cracker wrecks your system.
At the moment, that's handled somewhat by looking at the urgency field
from the changes file: most packages get uploaded with urgency low,
and are left for 14 days for bugs to be found, medium urgency packages
only get 7 days in unstable for bugs to be found, high urgency packages
get 3 days, critical urgency packages get 1 day. Note though, that if
a security fix is prepared for all architectures but one, then *none*
of the fixes will go in 'til the other is autobuilt.
> The version in testing might be older than the version in stable (if you
> e.g. upload a new package for 2.2r3 and the package from unstable never
> makes it into testing).
New packages for stable must have a lower version than anything in
unstable, anyway. The only special case is if the version in testing is
exactly the same as the one in stable, which is probably best handled just
by replacing the old package from testing with the new one from stable.
> Such things might e.g. be caused if you do a new upload of your package
> every week - so one package is never 14 days in unstable and a new version
> never makes it into testing.
If you're doing that, you need to either take a holiday for a fortnight,
so your last uploaded package gets included while you're at the beach,
or hax0r the urgency level up to "medium" or so so that it doesn't take
as long to get included.
On Mon, Dec 18, 2000 at 09:38:21PM +1100, Brian May wrote:
> Some other related points:
> 1. In the above case, I guess (at least the way I interpreted
> Anthony's post) that the latest package you have uploaded that meets
> the criteria will go into testing. So, just because you have uploaded
> version 2 yesterday, version 1 may still get through.
Nope, this isn't the case: the 14 days are intended to be days of
continuous testing. So if -1 is uploaded on the 6th, say, and -2 is
uploaded on the 10th; then by the 21st, -1 has probably only really had
four days of testing, not 14.
> However, what if version 1 was found to be buggy and unusable? How
> would the system know that version 1 was bad, but version 2 was OK?
That's the other problem. At the moment, it's just assumed that all open
RC bugs apply to the latest version in unstable, and that when they no longer
apply they get closed.
> 2. Is the unstable/stable field in changelog still used?
Yes: uploads to unstable go to sid, uploads to stable go to
potato-proposed-updates.
> 3. Nobody answered my previous question ("when do old files get
> deleted?"), so I may have missed the point in 1.
Note that the script to delete files from the pool only got written
yesterday, so that's one answer. The other is, roughly, when no active
suite includes the package or source (or maybe a day or two later to
let mirrors cope a little better, I'm not sure).
> Another unrelated point:
> 1. IIRC the BTS has tags potato and woody, to allow for tagging bugs
> as being specific to a distribution. What affect will package pools
> have on this?
Not really any.
On Mon, Dec 18, 2000 at 10:48:06AM +0100, Josip Rodin wrote:
> On Mon, Dec 18, 2000 at 03:44:55PM +1000, Anthony Towns wrote:
> > When woody is released, this will become:
> > stable: woody
> > testing: sarge
> > unstable: sid
> Have you decided on "sarge" already?
No, I just wanted a name to use, and it came to mind. (He's credited as
"Sergeant" in the Toy Story (one) imdb page you linked to, btw)
On Mon, Dec 18, 2000 at 04:20:24PM +0100, Wichert Akkerman wrote:
> Previously James Troup wrote:
> > Two words: package pools.
> From what Anthony said I gathered everything that is currently
> in woody needs to be moved into the pool.. that's a huge move.
Everything's already in the pool, it doesn't have to be in the pool/
directory on the archive for that. Files in the proposed-updates/
directory can and are in potato itself, files in woody/ can and are in
sid, and heck, files in woody/ are even no longer in woody.
On Mon, Dec 18, 2000 at 03:27:29PM +0100, Wichert Akkerman wrote:
[when things get added into testing]
> How will that move be announced? I would like to see an automated mail
> to debian-devel-changes and an note sent to the uploader (Changed-By
> entry in new .changes format).
I don't believe "Changed-By" is conveniently available any more after
a package has been in the archive for 14 days. A more useful notice might
also be "This package has been in unstable for a month, but still hasn't
made it to testing!". A list of those is available at
http://auric.debian.org/~ajt/update_excuses.html
with some reasons why, at least.
On Mon, Dec 18, 2000 at 09:38:49PM +0100, Santiago Vila wrote:
> Anthony Towns wrote:
> > In addition, unreleased architectures will only appear in unstable (sid),
> > not testing.
> I assume this is because if we were to wait for some packages to be
> recompiled for all archs (including unreleased ones) before moving
> them from unstable to testing, we would wait an unacceptable long time
> for some of them (is this the reason?).
The reason is that testing/woody is the next release candidate. If hurd
and friends aren't going to be released, then they're not part of that
release candidate.
One possibility worth considering is having the unreleased-archen
autobuild against testing instead of unstable: its known to build on
a bunch of architectures already, be consistent, relatively bug free,
and might fluctuate a little less than unstable does, if that matters.
> Would be possible to remove the requirement of sync with released
> architectures so that we could have testing for unreleased ones as well?
I'm not really sure I see the point of this: it doesn't particularly
help with the release (since they won't be released), and unreleased
architectures aren't particularly reliable for users no matter what you do
(or they'd be released!), so...
Cheers,
aj
--
Anthony Towns <aj@humbug.org.au> <http://azure.humbug.org.au/~aj/>
I don't speak for anyone save myself. GPG signed mail preferred.
``Thanks to all avid pokers out there''
-- linux.conf.au, 17-20 January 2001
Attachment:
pgpe_EsKhgNze.pgp
Description: PGP signature