Another "mere user" comment on the non-released architectures proposal
Hello,
this is my Very Humble (TM) opinion, as I do not have a significant
contribution to Debian.
First I have to say I understand the general spirit of the proposal.
Releasing on an architecture means making promises to the users, for
example that a significant portion of the packages in the archive will
be available, or that there will be timely security fixes. It's plain
normal to make sure these promises are realistic. I'll leave discussion
of the exact criteria to more knowledgeable people.
However, there are to points about which I feel very strongly:
1) that the portability bugs won't be serious anymore:
While shifting work to the porters does not necessarily mean dropping
the arch, not being able to build from a common source does for sure.
Common sources is what holds Debian together. An arch with their own
patches would be a different project already.
I understand that all bugs should be fixed eventually, but
discriminating the severity of portability bugs according to the arch is
clearly the wrong signal.
I would rather do something like this:
a) severity could still be serious, but only if a patch is provided.
This would put the responsability on the porters to work on the bug, but
make sure their work is not wasted.
b) if the maintainer fears the proposed solution might lead to breakage,
he could tag the bug etch-ignore. That way, arch-specific bugs don't
hinder the release, but by requiring an action from the maintainer, we
make sure the broken package doesn't enter testing when the maintainer
just needs one more week to test the patch, or when he is MIA.
2) that the is no clear "upwards" path:
For the sake of fairness (and ultimately freedom), it should be possible
for a group of sufficiently motivated porters to move their arch into
tier 2, and then into tier 1. While I understand that this part of the
proposal needs more maturation, I think it is important that clear
guidelines on how to do that are provided. This will help avoid
demotivation of the porters and draw the path for constructive work. It
will also avoid abuse of unrelated infrastructure, as seems to have
happened with the amd64 port.
Cheers,
BC
Reply to: