Hi,
Jeroen van Wolffelaar:
Steve was probably referring to the burden of fixing and debugging packages that fail to work/build on a specific architecture, and not to the buildd stuff. It is currently the package maintainer of a package that doesn't work on a specific architecture that's faced with his package not being allowed in testing, and s/he will is in practice the primary responsible for debugging, asking help, and fixing the issue.
Which is a good thing IMO, since said maintainers have less incentive to incorporate patches for SCC architectures if it hinders rather than furthers promotion into testing. Port patches are, at least to a non-insignificant percentage, likely to break other architectures. Why would I do that to my package, perhaps only five days after I uploaded it (= five days before it would enter testing)?
Simon
signature.asc
Description: OpenPGP digital signature
