Hi, I had several discussions with people on Debian lists that became very emotional. They thought that they were right in a discussion and I thought that I was right and nothing but anger resulted from these discussions. Several times the "opponents" in these discussions are people that are longer in Debian than I am and that do a damn good work in the area(s) they are working for Debian and I do acknowledge this even when they call me a troll. I try to summarize the most important points below - not because I consider it important that I'm right but because these are IMHO very serious problems in Debian. Please read it, try to understand it and make your own opinion of whether I'm right or wrong.
When I see problems somewhere I tell them even in the case when I don't know a solution - IMHO pointing to a problem is something valuable to help improving something. I do often try to see the point of view of the people we are doing our work for - our users. Everything I mention below isn't meant to offend against anyone personally. Debian becomes bigger and bigger. We do currently have over 900 people maintaining over 8000 binary packages [1] and there are currently over 350 RC bugs in packages that are in testing [2] plus many more in packages that were either removed from testing or never made it into testing. Debian is well-known for high-quality releases and I consider it important to preserve the high quality though we have so many different people maintaining so many packages. One important thing are more frequent releases. We don't have to release as often as other distributions but IMHO it's needed to have a new stable release at about once a year. Currently the software in our stable release is two years old and I see several distributors and magazines already ship woody CDs instead of potato CDs although we are still several months away from releasing woody - and if people encounter problems with the packages they find there this does in the long term harm the good reputation of the quality of our packages. There are many reasons why you need packages you can't find in potato. Sometimes it's only that you want to use Gimp 1.2 but often there are important reasons like e.g. support for kernel 2.4 or Euro support in some applications. Using testing isn't an alternative on many production systems because testing reduces the probality of bugs but it could still happen that e.g. your X does no longer start after your latest upgrade to testing. In Debian a package normally belongs to exactly one maintainer. The possiblity to overrule the technical decision a maintainer makes and to force a maintainer to e.g. implement a proposed solution from a bug report is mostly theoretical. This maintainer-centric approach gives very much power to a maintainer and I think that there also an obligation for a maintainer to take care of his packages. Most of us who work for Debian do this in our spare time. But I do personally disagree with the "you can't force a volunteer to do anything" argument I heard in several discussions. These were discussions about things where some work of the maintainer who is responsible for his package would save work for other people who do volunteer work for Debian or to improve the general quality of Debian for our users. Examples are e.g.: - Old RC bugs that are easy to fix. These bugs need someone to do a NMU and I'm often negative surprised in bug squashing parties how many RC bugs that are open for more than one month are easy to fix because there's e.g. only a missing build dependency. This makes it harder to get Debian in a state to release and it takes time at bug squashing parties to fix these bugs - time you could otherwise use to try to fix other bugs. Additionally one buggy package might prevent many other packages from entering testing which is very frustrating for the maintainers of the packages that don't make it into testing because of this. - Make debconf mandatory for all packages that interact with the user while installing/removing a package in woody+1. One positive effect would be for the user that he doesn't has to answer questions several times during the installation of the packages - he can instead go to drink a cup of tea after he answered the debconf questions that come en bloc. Another positive effect is that this makes life easier for everyone working on automatic installations of Debian. Don't misunderstand me: I know that a package maintainer also has "real life" things to do that might have higher priorities for him personally. On the other hand he is responsible for the packages he maintains and IMHO this implies that we can expect from a maintainer that he tries to fix RC bugs in his packages at least once a month and to try to fix the other bugs in his packages from time to time [3]. If it's generally agreed that all packages should comply with with something that is generally considered important I think it's OK to force all the maintainers to do such a change within a reasonable long amount of time (e.g. half a year or a year). There are already several places where we force a maintainer directly or indirectly to do something. The FHS transition was an example and another one is the setting of the Section and the Priority of our packages in the override file - if the ftp admins decide that a package should e.g. be only Priority "extra" the maintainer can do nothing do against it. There's another implicite way to force a maintainer to do something: Buggy packages get removed from testing or they never enter testing. At the first sight this is a punishment for the maintainer who doesn't fix the bugs in his package (besides the fact that with testing this punishment might also affect packages whose maintainers do maintain their packages perfectly). But if you look closer you'll see that it will harm Debian as a whole if popular packages like e.g. evolution that are currently not in woody won't make it into the stable release (many users will say: "What? Debian has so many thousand packages but this popular package that is in every other distribution isn't in the recently released Debian 3.0?"). Thanks for reading my mail Adrian [1] http://www.debian.gr.jp/~kitame/maint.rhtml [2] http://master.debian.org/~wakkerma/bugs/ [3] "tries to fix" means that he looks into the bug. I do expect a maintainer to be able to fix a "missing build dependency on xyz" bug or to forward the bug to upstream. OTOH it's clear that there are cases where the maintainer can't do much about a bug (e.g. there's an inactive/dead upstream and he can't fix a bug in the source himself).
