16 Responses to “Should we care about the numbers or the quality?”

1. Dan Douglas on July 12th, 2010 4:37 am

   Writing ebuilds and knowing that you’re doing it correctly, following best practice conventions, and taking in to account every possible gotcha is just really hard. After reading the devmanual I’m left with more questions than answers and still have an uncomfortably vague understanding. One to one mentoring is okay but I wish I could just read about it instead of digging through eclasses and thousands of lines of makefile Bash trying to understand how they work.

2. Rene Berber on July 13th, 2010 10:19 pm

   What about the quality of the maintainers?

   There should be some way to grade the work some “maintainers” are doing, and many would get a big FAIL.

   Those comments are from experience, I’ve tried to help keep up to date and properly configured a package, and a long time later a couple of “maintainers” come and try to spend less than 5 minutes, one just complains “you should make diffs”, the other at least tells the truth “I don’t understand your changes”, neither took the time to read the explanations and comments by other users, nor the further comments about the errors they introduced by “doing things their way”.

   I keep several local ebuilds which I maintain myself, I just can’t trust the quality on packages where the maintainers have a “don’t use/don’t know/have no time” attitude.

3. Kerin Millar on July 19th, 2010 12:47 am

   An interesting post and I agree that the level of QA is generally low (I could add a number of pet peeves to your list, not least automagical dependencies due to non-explicit configure options). However, I think it should also be borne in mind that – downstream QA aside – new versions of packages tend to fix important bugs. Given that this is a rolling distro and that it has no stable tree (in the sense that, say, Debian has one), maintainers who are predisposed to trying to stay abreast of upstream are not necessarily to be sniffed at. That is to say, I regard poor QA as largely orthogonal and a simply a sign of poor maintainership. So much so, that I am grateful even if maintainers bother to bump their packages these days, let alone invest any significant effort in ensuring their quality.

   To be fair, there are certainly some excellent and mature developers but there seem to a number of dilletantes as well. Before asking the user community for help, why not take it where it is already being offered? I’m reluctant to labour my point but I could point to a fair number of bugs where users have gone out of their way to provide high quality contributions and commentary to no avail. In one instance, the reporter had provided a significant number of patches and bug fixes and had invested time and diligence in doing so. In the face of obviously unresponsive/idle maintainers, I went so far as to copy a QA member in on the bug in the hope that they would marshal this good work. I asked kindly, but the bug stays open to this day.

   In another case, just getting a (small) package (trivally) bumped (thus fixing a nasty segfault) took well over a year. And that’s before even running the arch tester’s gauntlet.

   The most effective method I know of to get things done basically entails finding a developer who holds me in some regard (but isn’t necessarily involved with the package) and pleading with them to intervene, perhaps even to break protocol just to get the job done. In such cases where I have employed this method, the work is typically already done on my part and it’s the interminable last mile that remains to be traversed. If it were the case that a package were subjected to a thorough series of tests in order to establish its production worthiness, one could almost understand but it is obviously not the case.

   All of this is also a very effective way of discouraging further contributions. I can attest to it, Rene’s comment above alludes to it and I have seen similar comments elsewhere (most recently, in response to a rant from Flameeyes about QA, interestingly enough).

   Moreover, when the level of maintainership declines to the point where a herd can be reasonably deemed as dying (if not outright dead), there appears to be no safety mechanism for dealing with it. It is not even as if developers seem inclined to stick their heads out and say “Sorry, I just don’t have time – let’s see if we can delegate this to someone else or actively recruit someone for that purpose.” Instead, bugs are left to accumulate and there is nothing but silence.

   The trouble is, of course, it’s a thorny topic and any kind of criticism (even constructive) which naturally evoke an emotive response. In my experience, such responses have ranged from “So, why don’t you become a developer?” (I’ve been courted but have always stated quite honestly that the nature of my work would not allow me to exhibit the duty of care I think is necessary, and that it’s easier to pick and choose where I contribute; the notion that one can only contribute by being a developer is a fallacy); “you get it for free, you can’t complain” (the property of being free/gratis does not grant automatic immunity from criticism, and criticism often stems from a genuine concern); “nobody pays me to do this” (if one wants to be paid then it is illogical to agree to work on a vountary basis); “we don’t have enough manpower” (do we stop to ask why? can this be a generic deflection of a needed critique of any aspect of how the distro is administered?)

   Well, that turned out to be a little long. It’s not intended as a rant, but it remains a matter of great frustration. My opinion is simply that too few developers approach their work with the natural sense of duty that can stem only from maturity, commitment, diligence and conscientiousness. This cannot be exacted through preaching, coercion or even money so, for as long as the issue is not broadly recognised, nothing much changes.

4. Markos on July 19th, 2010 2:56 am

   Imho, your post represents the 90% or our userbase thoughts about Gentoo….and I couldn’t agree more with you

5. 2300 on July 30th, 2010 1:41 pm

   I don’t fully agree. Of course, QA is important and I don’t want to defend people who think it isn’t. However, it _does_ matter, for if a package I need is not in portage, I have to install it myself, which is definitely worse QA-wise than a package that just doesn’t respect {LD,C,CXX}FLAGS or bundles external libraries. (If I install it manually, the bundled libraries will be there as well, after all)

6. 2300 on July 30th, 2010 1:44 pm

   Hmm, my formulation is quite unclear. In “it _does_ matter”, it refers to “the number of ebuilds in portage”.

7. Ben de Groot on August 4th, 2010 6:05 am

   Kerin hits the nail on the head. There is no mechanism in place for packages that fall through the cracks, and user contributions go ignored way too often. This is one of the major reasons Gentoo is, slowly but certainly, dying…

8. Markos on August 4th, 2010 10:54 am

   Sad but true

9. Kerin Millar on August 4th, 2010 2:20 pm

   Perhaps someone could suggest to the Countil that a policy (or at least a set of guidlines) is needed with respect to maintainers or herds that are unable to cover their responsibilities, for whatever reason? I understand that Patrick is leading now; I think that the nature of this problem would be abundantly clear to him. I’m not suggesting that development talent grows on trees but recognising any given problem is the first step in attending to it. I’m going to cite a specific example now although they are by no means unique: net-proxy. squid is a package of broad public interest and needs a bump for security reasons alone. The ebuild in bugzilla is of at least equal quality to any existing instance of the tree, perhaps slightly higher. There are too many cases now where herd affinity is actually _impeding_ work from being done; not that I have any concrete suggestions as to a better model.

10. Markos on August 4th, 2010 2:37 pm

    Patrick is leading what? I don’t quite follow that

11. Kerin Millar on August 4th, 2010 3:02 pm

    The Council? I could be mistaken as I have not been following Gentoo’s internal affairs particularly closely of late. Not that it is overly important with respect to the broader point.

12. Markos on August 4th, 2010 3:09 pm

    No. Council is 7 member entity
    http://www.gentoo.org/proj/en/council/

    I already sent an email to gentoo-dev regarding the net-proxy/squid inactivity

    Lets see how that will go

    http://archives.gentoo.org/gentoo-dev/msg_d622eb6af88108094cee923af071cd51.xml

13. Kerin Millar on August 4th, 2010 3:25 pm

    Thanks Markos. Regarding squid, the consensus seems to be that squid-3.1.5 is a better candidate for committing/stabilising (along with the patches I provided) than 3.1.6. Whether it should stay ~arch is ultimately not our call, but if it does stay as ~arch then squid-1.2.x would need to be bumped as well. I’m happy to do the necessary work if I know that anything will come of it.

14. Markos on August 4th, 2010 3:46 pm

    I plan to act on that. Since I am not quite familiar I will probably need a user ( ideally you ) to proxy maintain this package. I will wait a couple more days to see if there will be any activity wrt my post on gentoo-dev ML and then we can work on it together if you like

15. Kerin Millar on August 4th, 2010 4:22 pm

    Thanks again. Feel free to contact me any time as you see fit. I use screen/irssi as well and my nick is kerframil.

16. Why should a package respect LDFLAGS anyway : Yet another open source blog ;) on August 13th, 2010 6:59 pm

    [...] my last post about Gentoo QA and Diego’s one , I will try to explain why this QA issue is that important.  As you already [...]

Leave a Reply