Re: [hertzog@debian.org: Re: Woody retrospective and Sarge introspective]
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.
> - Filespace
It's not much worse than currently. Really I don't expect that everybody
will always have separate version of packages for each distribution. Only
the more difficult package will use that possibility ... simple
packages may not need it at all.
> - Autobuilders
Yes, we'd need more autobuilders (or reconfiguring the one we have), we
did it for the security team, we can do it for "candidate".
> - Security-Updates
I don't see that it would be more problematic than unstable or testing
wrt security updates.
> - Somebody to take care of it
Take care of what ?
> - Time and effort from the package maintainers: They'd have to take
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.
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.
> care and track another distribution, temporarily inresponsive
> maintainers might break "candidate" even more than "testing",
> because no automatism is involved.
I doubt that. candidate beeing highly broken will result in a maintainer
getting bashed by other because he uploaded untested packages. And it
will certainly result in NMU if the maintainer is unresponsive.
And as I said, uploading packages to candidate is extra work, so I
expect that most people will use the possibility to move a package from
testing to candidate.
There's one problem with that however, because of the different set of
libraries that might be used in both distributions, moving is not
enough, one might have to recompile. An automatic recompilation doesn't
change the version number but here it should because the generated .deb
would be different.
> If people don't use "testing", "testing" won't be tested enough. OTOH
People already said that about "unstable" when we introduced "testing".
The fact is that a lot of people still use unstable and catch bugs
before they get into testing.
Things won't change with the introduction of candidate.
> 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.
> Why should he? Any effort he spends on 4.1 now'll be wasted, because
> it won't be included in any stable release, and takes time from him
> perfecting 4.2. The X strike force homepage as location of unofficial
> testing debs works.
Now that woody is released, it's not useful anymore of course. But while
we were finalizing woody, he couldn't upload XF4.2 to unstable because he
wanted to be able to update XF4.1 in woody...
With candidate, he could have uploaded XF4.2 into unstable sooner while
still having the possibility to finalize XF4.1 for woody ... and at the
present time we'd have XF4.2 ready instead of still waiting on it
because it has not been tested enough.
Cheers,
--
Raphaël Hertzog -+- http://strasbourg.linuxfr.org/~raphael/
Formation Linux et logiciel libre : http://www.logidee.com
Reply to: