Re: Opinion on splitting official architecture (tiers)
As someone with a PITA package that's frequently dealing every month
with strange issues on lightly-used architectures, I'd support a Tier
II system for i386/armel/etc. However, at the risk of making this
overly complex - I would prefer to see a bit more granularity on a
per-package or per-priority basis. For example, perhaps:
- Tier II architecture RC bugs in 'required' and 'important' priority
packages would still prevent migration, and package maintainers would
still be expected to fix them. They should (or must?) also be fixed for
a stable release.
- Tier II architecture RC bugs in 'optional' packages would NOT
prevent migration, and package maintainers do not need to actively work
on fixing them (although they should accept reasonable patches that fix
the RC bug). They need not be fixed for a stable release to happen,
although fixes for those RC bugs should be prioritized for subsequent
stable point releases.
- I'm not sure about 'standard' packages. I'd lean towards the same
rules as required & important.
Someone who has thought about this more should probably decide just how
functional a Tier II architecture need be. I could install an armhf
headless server machine with very few optional packages and be happy,
but if I had an old i386 desktop then I'd be pretty sad without a lot
of optional packages like firefox or chromium. So I could also see some
rule based on some kind of task-style package (but without the
task-foo-desktop|task-bar-desktop stuff) instead of priorities.
Reply to: