* Goswin von Brederlow
| Tollef Fog Heen <[EMAIL PROTECTED]> writes:
|
| > * Brian Nelson
| >
| > | Anyone, developer or non-developer, can help fix toolchain problems.
| > | However, the only people who can work on the testing-security
| > | autobuilders are ... the security team and the ftp-masters? What's
| > | that, a handful of people? With a bottleneck like that, isn't that a
| > | much more important issue?
| >
| > The problem is not the autobuilder infrastructure per se. It is that
| > testing and unstable are largely in sync (!). This, combinded with the
| > fact that testing must not have versions newer than unstable (they
| > will then be rejected) means testing-security wouldn't work at the
| > moment.
|
| How is that different from testing-proposed-updates?
t-p-u is not uploaded from another host through a mapping. (Remember,
uploads to stable are mapped to stable-security on
security.debian.org, then uploaded to stable from that host. The
.changes file however, does not list stable-security, it only lists
stable. And the trivial fix, to drop the mapping won't help either,
since then any DD could upload to stable by uploading to
stable-security, and we don't want that.)
Also, AIUI, t-p-u will mostly be used when there's a newer version in
unstable and you can't get the version in unstable in (because of
dependencies) or you have to get a fix in immediately, in which case
you upload to "unstable testing-proposed-updates", so you don't hit
the version skew issue.
| And why is testing-proposed-updates infrastructure still lacking 2
| buildds?
I don't know.
--
Tollef Fog Heen ,''`.
UNIX is user friendly, it's just picky about who its friends are : :' :
`. `'
`-
