Re: testing to be implemented on ftp-master
On Tue, Dec 19, 2000 at 01:45:35PM +1000, Anthony Towns wrote:
> 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.
Of course, there's still security.debian.org; but that's not really
relevant, since I doubt we'll be supporting security updates to testing
anyway.
> 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 more I hear about this feature, the more I love and hate it. It'll
get package building in shape real, real quick - but it's impractical,
I think. Consider the state ARM's in right now - the usable state that
PowerPC was in perhaps two years ago, with random gcc ICE's all over
the field. My most recent experience is that PHP4 (I think) simply doesn't
build on ARM.
> > 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.
And let's be a little more aggressive about this than we have in the
past, please. I'd rather just not allow stable/unstable uploads - all
too often packages need to be built separately for stable and unstable,
or are so built, and then the two uploads clobber each other in
incoming!
> > 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.
Seems like a bit of an abuse of the urgency field... Poor KDE in this
situation :)
> 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.
I sense the potential for endless months of confusion over that last...
remind developers to stop using locate and find on the archive to
figure out where things go :) With pool/ it is obvious that you need
to look elsewhere; with things left in woody/, though...
This is purely a developer convenience, and might not be worthwhile,
but what do you think of some small index in the pool directories
describing the status of each version contained in that directory? It
seems like it could be very useful.
> 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.
Now that we've got per-package directories anyway, could we please keep
this available? It's not that hard to save .changes that go with given
versions, and the extra information could be invaluable.
> > 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...
But it does make it easier to work out what the problems are for a
future release, I'd think.
Dan
/--------------------------------\ /--------------------------------\
| Daniel Jacobowitz |__| SCS Class of 2002 |
| Debian GNU/Linux Developer __ Carnegie Mellon University |
| dan@debian.org | | dmj+@andrew.cmu.edu |
\--------------------------------/ \--------------------------------/
Reply to: