Re: the new style "mass tirage" of bugs
David Nusinow <dnusinow@speakeasy.net> writes:
> This is something that's been bugging me for a while now. As our
> software packages get larger and larger, we need more people to take
> them on. To do this, we need more people willing to work with such large
> and difficult codebases. Unfortunately, the number of these people
> doesn't seem to rise at nearly the same level as the total amount of
> code we have to maintain in such packages.
> We could deal with this problem if we were better at training and
> recruiting people to work on such things. We've been lucky in the XSF
> lately in getting enough hands to get the work done, but I don't think
> there's any clear forumla from our experience that could guide other
> teams to do the same. I'd love to find one though. If we could do a
> better job of steering people towards these important packages rather
> than their vanity package of the hour, I think everyone would benefit.
There are two specific difficulties that I've seen that I think contribute
heavily to the ever-growing bug list problem:
* For large, complex projects, a lot of the bugs that don't get answered
are of the form "I tried to do X, Y, and Z with this package and it
didn't work or crashed," usually with the crash happening under obscure
or mysterious circumstances, without good information about what
happened prior to the crash or mistaken behavior, and often involving
obscure features of the package.
These bugs are very hard. Unless you know the code very well and can
make educated and lucky guesses at where the problem might be and how to
narrow it down, they are exceedingly difficult to reproduce in a
reasonable length of time. Furthermore, working for four or eight hours
to try to set up a test environment suitable for reproducing and fixing
an obscure bug is not interesting or rewarding work compared to
packaging new software or working on ten other bugs that can be fixed in
15-30 minutes each.
These sorts of bugs often are abandoned even for commercial products.
When they aren't, it's because someone is paid (via customer support
contracts) to do the tedious work of reproducing bugs no one really
wants to look at as a hobby. (It doesn't help that over half the time,
the problem ends up being some misconfiguration or other issue where the
only real change that can be made in the software is better error
handling.)
* Training people on how to contribute to a free software project, triage
bugs, write maintainable code, and fix problems appropriately is hard
work. I have a difficult time devoting enough time and energy to
mentoring as part of my regular job, and there I'm being paid to do it
and measured on it in performance reviews. It is sad, but nonetheless
true, that when I sit down to work on Debian in the evenings or on the
weekends as a hobby, often the last thing I want to do is try to walk
other people through learning how to program and do software
maintanence. That's *work*; I want to do something immediately
rewarding, like writing code and fixing bugs.
Some people really like mentoring and training others and find that
immediately rewarding. Those people are wonderful and deserve all the
praise we can give them. For the rest of us, I think it's often a lot
to expect of people. That sort of training is in many respects
significantly harder than all the rest of what one does as a DD. It can
be a lot of fun with just the right person and a great match of
personalities, but on a comprehensive, project-wide basis, you can't
rely on that match happening. In a workplace, you simply have to make
training happen even if it isn't loads of fun for both people. It's
much harder to do that as part of a volunteer project.
Not every bug falls into the first category, and I think many projects in
Debian do a great job with training. I'm not saying that the above
explains everything. But if you look across all of the bugs of some of
our large projects that have hundreds of bugs, I think that you'll find a
significant number of bugs in that first category where people just don't
have the time, energy, or desire to do the work required to resolve them.
--
Russ Allbery (rra@debian.org) <http://www.eyrie.org/~eagle/>
Reply to: