Re: [hertzog@debian.org: Re: Woody retrospective and Sarge introspective]
Le Tue, Jul 30, 2002 at 10:51:11PM +0200, Andreas Metzler écrivait:
> The handling of tags is not automated in any way (except NMUs). Take
> package foo which is the same version in sid, woody and sarge and has
> a normal bug: The maintainer uploads a bugfix to sid and the bug is
> simply closed and not tagged woody,sarge. Moving a package from sid
> to testing does nothing to the BTS, too. If you've got 4 different
> versions you have got chaos.
I'm sorry but going from 3 to 4 is not any likely to introduce much more
chaos than we currently have.
And the BTS certainly tracks version number ... when you file a bug, you
file it against a particular "version" of the package. After that you
have to know in which distribution that particular version is. This
information can be obtained with "madison" on any debian machine.
There's the question of affected distributions, and for this we have the
tags which are manually set when we need them.
> Afaik Debian currently has no security-updates for testing
I know that.
> If you want to have something that is supposed releaseable anytime
> i.e. "candidate" _imho_ you need security-updates. "candidate" looks
> like it is going to be older than testing, waiting for
> security-updates to trickle via sid and unstable to candidate might
> take too long.
Why do you think that we need to "wait" ? People can upload security
fixes to candidate as soon as the security fix is available.
Yes, that's work that has to be done. But we already have Matt Zimmerman
who is doing the work of making sure the security fixes end up in
unstable, we can have someone else for candidate if really needed.
> Somebody is going to have to do the actual coding, fix bugs, answer
What coding ? Creating a new distribution probably doesn't mean much
coding, just a bit of configuration on the ftpmasters side.
It means also a bit more work for the porters setting up the
autobuilders and managing them. That's the only real problem because not
all arches have enough man power to handle the additionnal work.
BTW, some people volunteered (just after the leader election) to help
that project if anything needs to be coded or done.
> questions, document it, basically the things aj does for testing.
I'm willing to document it where it's needed, starting with the
developers' reference. I already work on it from time to time.
> I did not try to imagine drawbacks, I just wanted to note what looked
> like showstoppers to me. (BTS, more work for maintainers.)
They are not showstoppers, only difficulties, but if we believe that it's
the right thing to do, then we'll be able to bypass/work around them.
> Ack. But currently you cannot upload packages directly to testing for
> a reason - they are supposed to be tested. Shouldn't "candidate" be
> "better" ie. safer than testing?
Yes it should. Because people are only supposed to upload tested
packages to candidate. It's possible to expect that from people because
they have unstable if they want to upload untested packages ... maybe we
can reject from candidate any package with a "-1" or "-0.1" revision
... :-)
Cheers,
--
Raphaël Hertzog -+- http://strasbourg.linuxfr.org/~raphael/
Formation Linux et logiciel libre : http://www.logidee.com
Reply to: