I was wondering if is right to our users that we are following only the RC bugs before a release. I think not. Don't get me wrong, I don't want important bugs count to be 0, or something similar; that would be insane to have as a goal.
I am thinking that we should (during the freeze) poke more of those important bugs that our and/or others' packages have. If you are like me, you will feel that you can't do anything/too much to improve the quality of the release during the freeze since some of the RC bugs are corner cases, not reproducible on your arch, already taken or you don't have the knowledge to fix them.
Many of the important bugs are broken functionalities that affect the users on a daily basis, and living 2 years with the same set of bugs is a pain. I don't know how that would feel, but I can imagine. I used Woody for only a half an year and after 2 months I started using backports. After 3, I started pulling things from Sarge (at the time it was testing). At the end of that half of year I was using mostly Sarge stuff and decided to go entirely into testing.
So, what do I propose? Maybe we should make some pages in the style of the RC bugs count pages which follow the important bugs.
As a bonus we might see some interesting things like bugs which were downgraded from RC - the RC graph would go down, while the important graph would rise. Of course, that wouldn't mean too much since that would be the product of badly assigned severities or downgraded and judged as non-RC bugs, but it would interesting to follow such tendencies.
2 comments:
Since ajt declared important bug no longer RC, noone cares about them...
As a user I support this idea. "Important" bugs are important, and nothing less. At least Debian should consider to adress them in point releases IMO.
Post a Comment