-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
Hi,
I like your suggestions in general, but am a bit worried about the results of
this:
On Thu, Feb 25, 2016 at 05:41:57PM +0000, Steven Chamberlain wrote:
> * If left unfixed, the bugs should trigger an auto-removal from
> unstable so that the package can migrate on the other arches. It
> also means the FTBFS bugs can be downgraded to non-RC, and helps
> packages to get back into a releaseable state. And it cleans up
> the archive, allowing old source packages to go away after
> transitions complete.
That would lead to ports with many missing packages too easily, I think.
Removing the package from the breaking port is an option, and it should be easy
to trigger, but it should not be automatic. If we make the process easy and
the maintainer doesn't do it (and also doesn't fix the bug), I think it is
reasonable to auto-remove the package from testing altogether (as we currently
do).
Making it easy to remove a package from one arch can be done in several ways.
Depending on the problem, this information ("don't build this package") may
belong on the buildd or in the package. If it belongs on the buildd, there
should be a blacklist there. Maintainers should be able to edit those
blacklists, for example through control@b.d.o. If it belongs in the package,
we could make it easier to specify Architecture: any-except-a+b+c. The current
system AFAIK is to list all the architectures that do work, which means that
such a package needs to be modified when a new release arch is added. That's
not good. Perhaps a new header can be added, such as "Except-Architecture:
arm, armhf".
While we're at it, perhaps we can define some architecture groups for use in
that header, such as "32-bit", or "big-endian"? Then the exception can target
architectures based on what breaks instead of just listing them. Those groups
should also be usable in the Architecture: field.
Anyway, perhaps I'm going too far now. My point in this discussion is that I
would like to make it easy for maintainers to make their package not build on
an architecture. If they use that, the package should be auto-removed from
testing on that architecture, so the old version does not prevent migration of
the new version. If they don't use it, the package should be removed from
testing entirely, just as it is now.
Thanks,
Bas
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1
iQIcBAEBAgAGBQJW0IvZAAoJEJzRfVgHwHE61qYP/Re+Dw5LGqd39VCCq/YGiJo7
q83CiJCsNauJWw9V7Y+tizw4h43SZ/CHrZp1Jhi2nU7W4b5dSZEYADpusEQEKfWV
5dqI4Us3fh595NWoRwR8s9UG8HnyvFl6Zt+5CScJLvtUCJXnY6IqNFoQXPz7AO+R
x7ht9SY8otkZ7NQBbvZpbtGnrX4TAwkpenAdYFLKpSxC6goQEbnlfeLxO2R8hDgD
E5g0M6SqGn/ClJ4Lnn10/r/9og3wBRBS+cIK/UsrhDtXrzbncq3ulXPZoznJxy4B
6W4OHjYr4im4QuhGPU2qiZP2VhBGjyi3s+Ds/oVlLZY+s8rtQHwy4PMXF8JjziNl
wdVpYR6H7+7sUHeeM2xH2hKi7Q84dJA0QlSGZdRy4yf5lnw9VH5BNs0NfeVltW0i
TmANygltxafQ4Z4wyiW+lx1R/JuuT9/0Q+5sFyczux+y/nJMKQf4LCSDV+TBXlbf
m+AcO4sLrBF7uOsVTwElw+n4+4rQ06RDzT8IP4sYW6MwOCNsjNzchbkEL5w1Y+KS
pcaI77LrqwwmQjC1MF/aCaeAXQNghRqfTpUkzmemnnjFm5KGSa6SyHI8DXYY+ox4
io7kEyBx6nAWgtQ8MUQ8S07DKvoSDKR/MSESeGqyfTEB4Ox1XFJT/hEX/eVrsCO9
MM4IhlyO5BkwSzE/lGWm
=VlPQ
-----END PGP SIGNATURE-----
