Even though I did read Donnie’s posts with his proposal on how to better Gentoo, I don’t really want to discuss them at the moment, since I have to admit that Gentoo politics is far from what I want to care right now, I have little time lately and that little time should not be wasted in discussing non-technical stuff, in my opinion, since what I’m best doing is technical stuff. Yet, I wanted to at least discuss one problem I see with most non-technical ideas about how to improve Gentoo: the bug count idea.
Somehow, it seems like management-kind people like to use the bug count of something as a metric to decide whether it’s good or not. I disagree with this ferociously because it really does not say much about software, if we consider as closed bugs that have just been temporarily worked around. It would be like considering the count of lines of code as a metric to evaluate the value of software. Any half-decent software engineer know that the amount of lines of code alone is pointless, and that you should really consider the language (it really changes a lot if the lines can contain one or twenty instructions each), and the comment-to-code ratio.
If the Gentoo developers were evaluted based on how many open bugs there are or on the average time a bug is kept open, we’ll end up with an huge amount of bugs closed for “need info” or “invalid” or “works for me” (which has a vague “you suck” idea), and of course “later” which is one kind of resolution I really loathe. The problem is that sometimes, to reduce the impact of a bug on users, you should put a quick workaround, like a -j1 in the emake call, or you’ll have to wait for something else to happen (for instance you might need to use built_with_use checks until the Portage version that supports EAPI 2 is stable.
Here the problem is that the standard workflow used in Bugzilla does not suit the way Gentoo works at all. And not everybody in Gentoo follows the same policy when it comes to bugs. For instance, many people would find that any problem with the upstream code does not concern Gentoo, others feel like crashes and similar problems should be taken care of, but improvements and other requests should be sent upstream. Some people think that parallel make is a priority (I’m one of them) but others don’t care. All in all, before we decide to measure the performance of developers based on bugs, we should first come over with a strict policy on how bugs are handled.
But still, open bugs mean that we know there are problems, and might or might not mean that we’re actively working on solving them, it might well be that we’re waiting for someone else to take care of them for instance. How should we deal with this?
I sincerely think that we should see to add more states to the bugs state machine. For instance we could make so that there’s a “worked around” state, which would be used for stuff like parallel make being disabled, --as-needed turned off and similar. It would mean that the bug is still there and should be resolved, but in the mean time users shouldn’t be hitting it any longer. Furthermore, we should have a way to take a bug off our radars for a while by setting it “on hold” till another bug is solved. For instance, the new Portage goes stable so we can deal with all the bugs related to EAPI 2 features being needed.
Then we should make sure that bugs that are properly resolved, and confirmed so, are closed, so that we can be sure that they won’t come up again. Of course it can’t be the same person who has marked the bug as resolved to mark it as closed, but someone else, in the same team, or the user reporting the bug, should be able to confirm that the resolution is correct and the bug is definitely closed.
But the most important thing for me is to take away the idea that bugs are a way to measure how software sucks and consider them instead a documentation of what has yet to be done. This is probably why trackers different from Bugzilla often change the name of the entries to “tasks” or “issues”; language has a high psychological impact, and we might want to deal with that ourselves.
So, how many tasks have you completed today?
You forgot to mention wtf/m in software quality evaluation methods: http://www.osnews.com/image…
I wholeheartly agree. For a user its very frustrating to have a bug scraped with ‘works for me’. This is especially true for uncommon arches, Throughout years I have submitted several bugs that were relevant to Solaris and half of the time I had to find a workaround myself. Even today, building, i.e. php with some extensions enabled is a hell on solaris.
This is mostly a comment on the bit below from your first paragraph.bq. I have little time lately and that little time should not be wasted in discussing non-technical stuff, in my opinion, since what I’m best doing is technical stuff.I’m glad you recognize where your skills are. You were, perhaps unfortunately but I think fortunately in the end, “forced” into it by overextending yourself and getting sick, but I’m glad you realize it now. There really are few people, in Gentoo, in the FLOSS community in general, and in live in general, with anything like your technical skills and understanding. You’re a rare resource not to be squandered and I’m glad you’re learning not to squander /yourself/. Not anyone can for instance be a council member, but way more can do that than some of the stuff you do, stuff that NEEDS done but that there’s altogether too few to do it all.OTOH, Donnie has both a great deal of technical skill and a huge level of organizational skill. He seems to have had an outsized effect on the council effectiveness, driving it to several times what it might be without him, so I’m glad he’s investing the necessary time and energy there. Somebody with the skills and motivation needed to, and he did.So I’m glad Donnie’s on the council and you’re concentrating on technical stuff. =:^) There’s a saying, Aces in their places, and I’m glad both of you seem to have found the places you’re aces and be investing your time there, now. Gentoo is definitely the better for it and while no one’s irreplaceable if it comes to it, surely it’d take more than one person or multiple times the time to replace either of you… if the job got done at all.