Hi, if you allow me to share a thought here even though I am not a developer and as such do not have any say in this.
Matthew Johnson wrote: > My goals with changing the membership procedures are: [... snip ...] While the aims you list themself may be laudable to achieve improvements, your *goal* with changing the membership procedures should look something like Aid Debian to recruit skilled, cooperative, and highly dedicated new volunteers and ensuring that Debian membership is only given to people having these necessary qualities. Your idea of a good goal may vary, but ultimately, your goal should be about membership, not process. Debian desperately lacks a vision for developing its membership and sjould develop that to derive an adequate process. Believe it or not, if you step away from Debian and look back on it after a few weeks, is seems miraculous that Debian does attract a fair amount of wonderful people and manages to keep a lot of those around. Let me put some observations here - I am not sure if any of the current listmaster team follows debian-devel.[1] I is commonly advised to stay away from core Debian lists to avoid being sucked into the misery that must strike anyone looking at e.g. January's -project or February/March's -devel. Does this say something about Debian? Does it impact the development Debian's community? - The commitment of people to Debian varies greatly. When I last looked at the end of 2008, about 350 Developers had not participated in Debian lists for one year at all. (Hint: this includes the -changes lists, so they have not been too busy uploading great packages to not contribute to discussions.) Yet, Debian needs people contributing very large amounts of time. The FTP team recruitment mails ask for 5 to 10 hours per week, every week, to be spent on that task alone. I have contributed some four-digit number of hours on Debian in 2008 (comparison: a full-time job is about 1900 hours per year, although I have to admit that my regular employment got the most productive hours) and yet I can name a dozen people contributing far more faster than I can blink.[2] Now, sparing that much time is something that is not generally possible and lots of smaller contributions add important value to Debian, but the habit of telling the release team how they should do their job while refusing to do minimal research or committing even the faintest amount of time beyond your own package is entirely disrespectful to those more involved. Also Debian would benefit from establishing an expectation of a minimal commitment. I do not think that it is something that needs codification and enforcement, but realistically, if people who cannot afford a few hours per month on average should look at moving to emeritus status until they can reasonably contribute again. This involves keeping up with Debian enough, too. How surprising is it that people get irritated when you did not hear about the freeze that has kept everyone else busy for more than half a year[3]? Having so many of the people offering a lot of time to Debian spend (waste) that on coping with undermaintained parts of the archive hampers both efficient work and stalls innovation in Debian. It is *absolutely* *100%* *scandalous* that Adeodato even had the chance to NMU half of the current set of transition-blocking bugs. This is the guy (well, one of them, no offense to the others) supposed to do release *management* and who is most qualified to improve the tools of the release team based on the experience with lenny and yet 999 Developers (of about 1005) let him delve in the minutiae of fixing #include statements? Shame on Debian! And it is not a wise thing to do, either, and not healthy to burn through a release manager every release. (And, Matthew, if you allow the personal comment, the best way to make a strong point about best procedural practices for NMUs is to put up a few of well-briefed NMUs instead of announcements how you will vote on fictitious changes to things not usually voted on.) Look at how Debian still is famous for apt et al. Debian could much more easily maintain a lead with the ideas that float around (e.g. debtags) if less time was spent fixing neglected packages and chasing around MIA maintainers. I should note that Steve's platform contains some allusions to responsibilities of each developer, but it did so last year, too, yet there was little visible activity here, but this is not -vote, else I would have commented on the orthogonality of exhibiting consensus and not being numbed by endless discussion above. - Debian does attract some very awesome people. But it also has accumulated too many process-obsessed mediocre contributors with exceedingly big egos who have little value to add to Debian. I hate to say it, but Debian desperately needs to find a way to stop some people to continue to follow patterns that harm Debian. Based on my observation that prominently includes people delivering sub-par quality work for whatever reasons and inflicting that on Debian. Also, one gets very tired of so mainy maintainers thinking they should be exempt from this and that because their package is so special. Part of a maintainer's job is to make the software fit into Debian. If you fail there, it is your problem in maintaining it, not a problem of upstream not serving things on a silver tablet. Discussing membership while eclipsing the need to deal with problems after people become part of Debian is undoubtedly more comfortable but also quite careless. > Being part of the project, particularly with upload rights, is something I > believe _should_ be difficult. This restriction on access to the archive is > one > of our strengths, it gives us a higher quality of packaging (yes, there are > exceptions, but they should be the exception, not the rule) than would > otherwise be possible. I would go as far to say that whatever is wrong with NM, it is not that it is too difficult. Sufficiently qualified candidates have no problem finishing current NM in a month or two. It is OK to take longer, but really, the NM process is more tedious and Debian gets too little out of the effort spent there, but difficulty is the least of its problems. > I don't think that just "be able to revert things" is a good answer, sadly. A > few reasons: firstly, it implies people are checking all the packages (which I > really don't think will happen) and it overlooks the problem that reverting > changes can (think: transitions) actually be quite painful due all the related > packages which need to change. It also puts too much extra work on the people currently cleaning up after screw-ups happening in Debian as is. 800 of 1000 developers did not care to help one bit with releasing lenny beyond their own packages, and the lion share of that work was done by some 50 people. Mind you: comparing Debian to Ubuntu: About 50 people are in ubuntu-core-dev (uploading to main) and about 70 more allowed to upload to universe. Membership in teams having those permissions is subject to expiration for inactive members. Kind regards T. 1. Mainly inspired by damog's most recent post. 2. This is, mind you, any one's ticket into the "cabal": spend vast amounts of time trying to put out quality work. 3. http://lists.debian.org/debian-release/2009/02/msg00083.html -- Thomas Viehmann, http://thomas.viehmann.net/ -- To UNSUBSCRIBE, email to debian-project-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
