On 2011-03-23 09:14:04 Geronimo wrote: >For me its a debian QA issue. > >grub may have bugs, as well as linux kernel - and of cause, each bug may >break a system or lead to fresh installation, which does not work. >That's no problem - if it happens at sid or testing. > >... but for me, its completely unacceptable having this happen to debian >stable. > >No other linux distribution has that QA-level of debian, so it may happen on >every other linux too. > >Debian stable is a synonym for really good (and unreached by others) QA - >and this has been broken now. Nothing really changed in this area around Squeeze release. RC bugs are tracked and resolved with new uploads, downgraded, ignored because they don't affect testing-that-will-soon-be-stable, or specifically tagged to be handled with an update to stable. If no one has issues with testing / sid, or they have issues and don't file bugs, then it won't be on the release team's radar. With things that are remarkably hardware specific (like GRUB2) it's not really possible for a DD to test your configuration unless they just happen to have it as well. With certain other things (like FTBFS issues) there are DDs that, as time permits, run through the entire archive and file bugs for such QA issues. There's usually plenty of time between freeze and release. If you want to make sure the release works for your configuration, test the upgrade / install during freeze and file bugs. Even if something won't be fixed (i.e. using kernel device names in /etc/fstab is fragile), it can be turned into information / documentation contained in the release notes. Also, Debian doesn't control upstream. When KDE decides to abandon KDE 3 or the GRUB developers decide to abandon GRUB1, Debian *has* to follow.[1] For the vast majority of programs in Debian, there are not enough DDs interested in that software to maintain it without support from upstream. [1] FWIW, GRUB2 and KDE SC 4 are both much more capable and featureful than their predecessors.[2] They do lack the "finishing" that KDE 3 and GRUB1 got through years of being deployed in production. Some of that "finishing" is missed; much of it really was "cruft" that just made it harder to improve the systems. [2] Let this not be interpreted as approval of the development process for either of these projects. As a maintenance programmer, there's plenty of code I've wanted to throw out and just re-implement from the ground up. But, the more I do it, the more I get the sense that that is rarely, if ever, the correct way forward. I would like liked to see the changes made in both these projects made more incrementally. -- Boyd Stephen Smith Jr. ,= ,-_-. =. bss@iguanasuicide.net ((_/)o o(\_)) ICQ: 514984 YM/AIM: DaTwinkDaddy `-'(. .)`-' http://iguanasuicide.net/ \_/
Attachment:
signature.asc
Description: This is a digitally signed message part.