Re: [hertzog@debian.org: Re: Woody retrospective and Sarge introspective]
Raphael Hertzog <hertzog@debian.org> wrote:
> Le Tue, Jul 30, 2002 at 03:47:07PM +0200, Andreas Metzler écrivait:
>> - BTS needs to really no how to associate bugs with versions. (I know,
^^^^^^^^
>> we want this any way, but "candidate" _requires it.)
> This is ridiculous, the current testing scripts already have to know
> which distribution is affected by a bug.
> And we already have tags to mark some bugs as distribution specific.
^^^^^^^^^^^^
> It would not be difficult to change reportbug to add a default tag
> "candidate" if one is running candidate or something similar.
[...]
Hello,
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.
>> - Security-Updates
> I don't see that it would be more problematic than unstable or testing
> wrt security updates.
Afaik Debian currently has no security-updates for testing
(testing-security was only a misnamed frozen-security)
| From: Wichert Akkerman <wichert@wiggy.net>
| Date: Fri, 14 Jun 2002 08:43:54 +0200
| To: debian-devel@lists.debian.org
| Subject: Re: developer's guide to security updates
| Message-ID: <20020614064354.GI21889@wiggy.net>
|
| [...]
| > Also, what will happen with security updates to testing once testing
| > has been unfrozen after the release of woody?
|
| They'll probably get rejected since it does not make any sense to upload
| security fixes to testing if it isn't frozen. Security fixes need to be
| tested just like other packages and will have to go through unstable.
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.
>> - Somebody to take care of it
> Take care of what ?
Somebody is going to have to do the actual coding, fix bugs, answer
questions, document it, basically the things aj does for testing.
>> - Time and effort from the package maintainers: They'd have to take
>> care and track another distribution,
> Because you think that the introduction of testing simplified the work
> of maintainers? Look the pain that it is to follow update-excuses to
> see why your package is not entering testing.
No. Because of the reasons I wrote. They'd have to take care of an
additional version of their package in the archive, move it to
"candidate" when it is ready, perhaps make additional uploads.
> Come on ... don't try to imagine drawbacks. Let's first see if you think
> that implementing that solution might help in our release management
> process.
> After that, if we think that yes it would help, then we'll consider the
> drawbacks and we'll see how to handle them.
I did not try to imagine drawbacks, I just wanted to note what looked
like showstoppers to me. (BTS, more work for maintainers.)
[...]
>> candidate might break because of the untested packages ("But he can
>> also make direct uploads to "candidate"").
> Sometimes you have to trust people, automated tasks will never give
> you the quality you're looking for.
[...]
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?
cu andreas
Disclaimer: If this mail was inpolite or rude I apologize, this was
not inteded but caused by my bad comand of the English language.
Reply to: