Re: the new style "mass tirage" of bugs
On Thu, Feb 21, 2008 at 10:37:37PM -0800, Russ Allbery wrote:
> 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.)
Right, this is why I think we need to do a better job of steering people
towards working on these large and complicated codebases. Like Steve, I
don't think this is a place for casual people to dabble in, it's just too
difficult. At the same time, because these packages are hard people are
scared of them, and the packages and bug submitters don't get the attention
that they really need. I think we need a good way to get people over their
fear. I've suggested that new contributors that they join a team so that
they can get this sort of experience, but I don't think this has really
done much so far, so we're probably doing it wrong. Perhaps we need to
dangle a carrot for NM's. "If you worked on a big team in a useful way,
you'll get through NM way faster," might be a good method.
> * 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.
Exactly, but I really think that these aren't mutually exclusive things.
Working on the bugs requires looking at the code and, ideally, writing code
to fix the bug. My feeling is that if people are used to a package then
they'll get in there with the code doing the fun work when they get a bug
report. Unfortunately, we have so few people on the larger packages right
now, that there's not enough time for them to do this effectively. More
hands would free them up to do both the grunt work and the fun stuff that
comes with it.
- David Nusinow
Reply to: