[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

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.

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: