[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Another "mere user" comment on the non-released architectures proposal


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.


Reply to: