[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: Debian Membership



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/


Reply to: