I’m quite sure that some of the possible voices stirred by my previous posts, and about my less-than-happy comments on Sunrise, is that I dislike or look down on user contributions. All the opposite, I actually think that user contributions are the heart and blood of Gentoo. But I have some particular views about them.
One of the most common approaches for user contributions in Gentoo when I joined was never to do the work in place of the users: get them to fix their ebuild, point out what needs to be worked on, and leave to them to submit an updated ebuild. I shared this sentiment for a while, but nowadays I don’t think it’s the best approach. Since, as I already expressed, there is no good documentation for Gentoo development, it’s difficult for the users to provide good ebuilds by themselves. And sincerely, there is too much old cruft in the tree that shows just a bunch of bad examples.
This works only to a point: those most interested in the inner workings on Gentoo might pick up the opportunity to improve their ebuilds; many others might just feel turned down and will stop caring about their ebuilds; or about Gentoo as a whole! This post by Stephan Gallagher points at something similar.
Now, most of us will agree on the point that the situation where the user stop caring about the ebuild, or decide to keep it in his or her overlay is not good for Gentoo as a whole, but there are two approaches on how to solve this. The one that I openly dislike, and attack, and is followed by the one developer I kept criticising, is to take the ebuild, even though “suboptimal” and commit it to the tree as the user contributed it. I think it is easy to see how that can be a problem.
My favourite approach, instead, is to fix the ebuild; try it out, get it polished, if needed contact upstream to fix possible issues… it might take extra work, even for something you don’t use or care much about, but it gets results handy. To take an example from the past months: Pavel contacted me about gearmand and drizzle; while I’m using neither and I wouldn’t have had time nor interest to write ebuilds for them out of thin air, I gave him a few pointers, and he got back to me with updated ebuilds; they weren’t perfect but they were a good starting point. I polished the ebuilds a bit further, sent upstream a few patches, and now Pavel is still maintaining them, and they seem quite fit for the job to me.
Saying that Pavel’s original ebuilds weren’t fit for the tree, and weren’t good enough, is not the same as insulting Pavel; I’m quite sure he agrees that they weren’t perfect; I’m also quite sure that his next ebuilds “out of thin air” will be better than them, since he has been able to see how some of the things were to be done. Something that, lacking a good documentation, is impossible for users to do without developers’ help.
Sometimes, it’s also easier to go upstream and fix some of the troublesome build systems before going on further with the ebuild, as Enrico will probably remember from the Gource work. But again, you shouldn’t be confusing showing users (and other developers, or developers from other projects) how to do the right thing, and criticising them.
*The perfect is the enemy of the done.*