Re: How to be a great Debian Developer
Hi, Thomas.
On Tue, Jan 28, 2003 at 08:55:32AM +0100, Thomas Viehmann wrote:
> Taking your answer literally, the conclusion is that you think that debian
> has enough package maintainers and the others should bother about the crums
> that fall from the table that existing DDs are not interested in.
I don't think Debian is necessarily better off for gaining more main-
tainers. More maintainers who are productive are great, but maintaining
a package currently means that no one else maintains it (6-month waits
and NMUs aside), and that one person "owning" a package and poorly
packaging it or neglecting it means that a package that is potentially
very useful is useless.
Unfortunately, it's hard to tell who is serious about Debian and who is,
for instance, likely to do work for a month, decide RedHat is what they
want to run at home, and never be seen again.
A long NM process used to weed out people joining Debian on a whim
(good), but it also weeded out good developers with a low tolerance for
bureaucracy (very, very bad). Now that it's relatively simple again, I
thought I'd send a cautionary note to new maintainers, asking them to
consider carefully why they're applying.
There _is_ more to do than "crumb"-work, but everyone has to do the work
that is no fun at all, too. When newbies realize this, they're not as
likely to stick around.
>[...]
> I've thought about packaging quite a few things before, but now I think I've
> found something truely worthwhile.
That's great. If you want to maintain it yourself, then welcome to
Debian!
> Why would you expect anyone to write the manpages the package maintainer
> doesn't bother about? True, there are those maintainers that don't have the
> time because they're doing very much for the project, but for the most part,
> I cannot help but think that they just don't care. I did write two manpages
> for my own package because that is the lintian warning that's still left, but
> you should well know that a volunteer project needs to distribute the dull
> jobs amongst those that are working for the main cause.
No it's not fun work, but someone has to do it. I'm not claiming that
all current maintainers do things correctly -- quite the opposite.
(Some people in Debian suggest that N months of that sort of work should
be a prerequisite for getting the ability to upload new packages. It's
informal grumbling, so don't expect it in the NM rules soon.)
I was pointing out that there are ways to help Debian for which one
doesn't have to go through NM.
> With wnpp matters are even worse, because for the most part, they are just
> "ugly, pointless packages noone in the world would care about". (There are
> notable exceptions every once in a while, but mostly this is the exact reason
> they're abandoned in the first place.)
This is true. A significant fraction of the packages you see are the
tangible results of Joe Debian packaging his own software.
More software authors filing RFP bugs instead of NM applications would
help. The request/claim buffer of WNPP would keep out a lot of "useless"
stuff.
> In addition, "helping out maintainers" is something that strongly depends on
> the willingness of maintainers to accept help. In my experience, the quality
> of the packages is strongly correlated (maybe even causal, not coincidental)
> to the willingness of maintainers to accept help and user comments and their
> friendlyness to answer questions.
Yes, and if you're on debian-mentor, you're probably a personality that
doesn't mind getting help, so I have nothing to add here.
> Let's face it, the main cause of problems in
> debian are the problems of and with the present developers and do not relate
> very well to future developers.
I've said "these are the problems." Will readers of this contribute to
the problems or help reduce them?
> [...] Don't expect anyone to join
> debian just to do the odd jobs and wanting to be "a slave to Debian". And
> don't think that telling people "the contribution you want to offer is not
> needed, please do the stuff we don't like" is a successful way of getting
> anywhere.
I guess that depends on what I consider "success".
I don't want to send away good developers, but in my estimation when
four people join, the first is productive, the second is an obstacle, and
the third and forth (who could have been productive) are stuck cleaning
up after the second.
I really want a way to avoid #2. I fear there isn't one, though.
- chad
Reply to: