David Nusinow <[EMAIL PROTECTED]> 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 ([EMAIL PROTECTED]) <http://www.eyrie.org/~eagle/> -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]