Re: Debian Membership
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
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. 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
- 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.
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?
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.
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.
Thomas Viehmann, http://thomas.viehmann.net/