Hello Bernhard and everybody, I think that the ‘RPM hell’ that you used to comment my propositions is more related to a situation when independant distributions are using the same package format, than when a distribution offers multiple repositories that obey to a policy that keeps the whole system functional. We actually enter in the era of the ‘DEB hell’ since the success of Ubuntu, with users asking support for cross-distribution package installation. In the end, it is more a communication problem than a technical problem. We should make it clearer that it is not because the packages do not carry the distribution name that they are not specific to a distribution. Perhaps a page about ‘our packaging system’ for end-users on our website?
Regarding my proposal, that is internal to Debian, I do not think that it is impossible. What I propose is a way for package maintainers to signal that their package is peripheral in the Debian system, in an opt-in manner. Debian is running out of manpower, and I think that it will be useful to let know that a given package can be given a low priority for tasks. In my experience, trivial RC bugs on not-so important packages attract volunteers because it is very rewarding to close RC bugs. Also, I learnt a lot by participating to the ‘bug sprint’ organised by Josselin for Lenny, that we should not be discouraged to challenge a bug that is far beyond our technical capacities, because help like triaging and pinging the reporters is very useful and frees skilled hands that are much more useful at other tasks. So in my opinion, not all RC bugs are equal, and a better priority system would be useful to help volunteers to chose their focus. Our current priority system does not fit that task. Because of the rules about conflicts, important packages like postfix are of priority extra. By refactoring our priority system, we could make a much better usage of a priority level that really means ‘extra’ in the sense of ‘do not bother if you have more important things to do’. With a priority system improved along this direction, I think it opens the possibility to let some architectures release without the least important packages. Once I reported upstream that his scientific software was not working on Sparc. ‘I know‘, was the answer. This software, I want to bring it to the scientific communauty, and like the upstream author, I know that no researcher is seriously considering running it on Sparc for work. Why not distributing it only on amd64 until a user requests it on another architecture? Even on the other platforms where it builds, I have no clue if it works. And in my experience, the more regression tests I enable in my packages, the more I realise that they do not work on the platforms that neither upstream nor the users are using. I am very tempted to go even further and would like to distribute some packages for the stable distribution only through official backports for instance. Also, in my field, while people usually want to have the latest version to start with, they also do not want to change in the course of their analysis. I hope that the future package snapshot system will help us to satisfy this need. In conjunction with system image builders, Debian pure blends and ‘cloud computing’, it will be very powerful. Will it make the release easier? I think so, even if it is definitely not a magical wand. It transfers some responsabilities, and the work load that comes with, from the release team and the porters to the maintainers of leaf packages of low priority. I would like the Debian project to trust more its maintainers, and allow this transfer. Have a nice week-end, -- Charles -- To UNSUBSCRIBE, email to debian-vote-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20100327061703.ga28...@kunpuu.plessy.org