On Thu, May 15, 2003 at 01:10:35PM +1000, Anthony Towns wrote:
> On Wed, May 14, 2003 at 01:27:12PM -0400, Matt Zimmerman wrote:
> > This is an excellent point. Testing users do not expect updates from
> > securit.debian.org, so there is no reason that they need to be kept
> > there.
>
> Not putting them there, means not taking advantage of the buildds that
> automatically build uploads to the security archive, the nice, memorable,
> domain name, or any of the mirrors of debian-security. That's not "no
> reason".
There are no mirrors of security.debian.org, and have not been for as long
as I have been aware. See the security team FAQ.
I don't consider the domain name to be a serious justification.
Do you honestly think would be a good idea to use testing-security this way
on a continual basis? Such an endeavor would not seem to require any of the
facilities which make foo-security different from foo{,-proposed-updates}.
If you think this makes sense, why not run a testing-proposed-updates
instead? Or even allow uploads directly to testing at the maintainer's
discretion?
> > This is a related, more general issue, of how to minimize the blockage
> > introduced by package dependencies. I think this problem is much more
> > worthwhile to address than security updates targeted at 'testing'.
>
> You're wrong: blockages can never be cleared quickly enough to make for
> timely security fixes. For security fixes, "timely" is "same day"; for
> testing, "timely" is "a couple of weeks".
(setting aside the question of whether you can declare my value judgement to
be "wrong"...)
Finding ways to minimize these blockages would benefit all packages'
progress into testing, security fixes included, and thereby greatly benefit
'testing' users, whatever their motivation might be.
Sidestepping the process to provide this kind of "timely" security update
for "unreleased" software, on the other hand, doesn't seem particularly
valuable to me. If someone wants to provide this service, of course, that
is their prerogative. However, this does not seem to have anything to do
with security.debian.org, the security team, or the foo-security
infrastructure.
--
- mdz
