В Thu, 18 Mar 2010 00:02:56 +0900, Charles Plessy написа: > Le Wed, Mar 17, 2010 at 03:49:16PM +0200, Yavor Doganov a écrit : >> * There should be an entitiy within the project to decide which arch >> gets released and which not > I do not completely agree with this: > > I think that the porters should have much more latitude on how to what > their port contain. If they can assemble a reasonable subset of Debian's > packages into a working system that matches the expectations of the > users and that Debian can be proud of.
Interesting. Are you suggesting that bugs (mostly of the FTBFS type) should be ignored at the discretion of the porters and other important teams on a per-package basis (e.g. "Nobody in their right mind would install `foo' here, so it's OK to ignore the bug")? I think that this is a dangerous path to follow. IMHO it is the fastest way to *prematurely* kill an arch. Problems will start to accumulate, and issues with non-trivial inter-dependencies (e.g. resolving one major bug depends on the fix for another, sometimes in a different package) will pile up on the TODO stack, which at some point would inevitably lead to "enough, this arch is problematic, so we have no choice but to exclude it from the release". Ideally, all architectures should be equal (in practice they are not, but theoretically the criteria are the same). If the project allows the lapses you seem to suggest, that would be the end of all but mainstream archs. IMVHO. > Architectures that lose their mainstream position and therfore > upstream support in popular heavy-weight applications could survive > much longer. I seriously doubt that if your view/plan is in force. IIRC, this plan was discussed on -m68k (at least) several times in the past, and this is a plan to hide bugs, to sweep them under the carpet. YMMV, of course. (Just as a side note, you would be surprised how much "impossible to use" complex/heavyweight packages people install and run (even for testing purposes) on slow architectures. It is hard to predict the limit of users' patience, therefore I conclude that it is not possible to state with certainty "package foo is not suitable for arch bar because of performance reasons". And yes, I say this from the standpoint of experience -- my home machine park is "Jurassic", and still I manage to do what I intend to do with the tiny computer power available.) > if nobody wants to fix the bug, it is a good indicator that > everybody has more important, more rewarding, and in the end more > fun things to do, and that we should trust their judgement by > changing our release strategy instead of maintaining an institution > that opposes people. I disagree with this sentiment, but who am I to disagree... If nobody wants to fix the bug, this probably means that the majority of users are not affected by this bug. However, it has always been my understanding that a Debian package maintainer should look a little bit more forward than her own packages, and should do her best to ensure that everything she maintains is at least buildable on all Debian architectures, including unofficial ones (whether former stable ones or new, struggling to become official). -- 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/hntf4s$k...@dough.gmane.org
