This blog is named after a book I’m currently reading in my (very rare) spare time. The Tao of Negotiation is an interesting book on conflicts resolution and avoidance, and no, I’m not talking of diff rejects 😉
Why I’m using this name, and refer to that book? Well first of all because I really suggest that book to anyone who wants to work “happily” on a Community-driven project. It helps understanding why conflicts happen, and what you can do to prevent and resolve them without ruining your own health. This is something that, I have to say, is proving useful to me, especially considering that my gastritis (due to stress) was really hard to deal with before.
I had conflict problems when I was a gamemaster in an unofficial Ultima OnLine shard, four or five years ago, and that is my root cause for the gastritis. Add to that many obnoxious classmates, and you have the perfect recipe for an ulcer. I gave up that shard after a while, and I started working on NoX-Wizard, an UO emulator; even that wasn’t conflicts-safe, but at the end, I just forked the project when the main lead (Luxor, that’s you 😉 ) left the project too.
Now, since last year, I’m almost 100% concerned with Gentoo, and this is for sure not conflicts-safe; it’s more likely a continuous conflict problem that persists over and over and over. Why? Maybe because of the so-called “critical mass”, maybe because there are many people working for many different goals.
The latest one, that I usually avoided to talk about in this blog, is due to Project Sunrise. Let’s try to analyse the problem in detail. Some developers wants to resolve the problem of ebuilds lingering in bugzilla in a limbo state, and as we can already seen it’s difficult to manage the currently added ebuilds with the current staff, they want to make users part of the process with the Sunrise Overlay. Other devs are concerned that this is going to be a QA mess, that it will create more problems than one might expect, that it might inject dummy bugs in bugzilla that people will have to take into consideration.
But are those the actual reasons? I doubt so. Let’s start from the overlay idea. There are already tons of overlays, I also did have mine before becoming a developer, a quite big one too, one more, by itself, cannot really change the facts. Not even being an official overlay is going to change much into the whole figure.
The problems here are mainly two: the first is that both parts are closed on their decisions; people working on Sunrise wants it official and will continue asking for that, people against Sunrise continue repeating their concerns about security, QA and so on, they don’t want to listen to each other; the second is that people against Sunrise fails to express what they really think, at least in my opinion.
Now, I hope nobody will have bad feelings about me if I try to express this clearly. I think one of the main concerns of people is with Stefan (genstef) and Jakub being the main reviewers. Why? Well.. Jakub is not an ebuild developer, he didn’t pass the quizzes and so on, and while I was able to notice with my own eyes that he knows some common quirks that even old-time devs fail to see sometimes, he hasn’t proved its ability, as we don’t see ebuilds from him in the tree; Stefan instead, although being an ebuild dev, had a few screwups in the past that might arise people concern (Stefan, don’t take this personally, there are a few things in your style I don’t like, neither, like the hard usage of live svn ebuilds even for snapshots for instance).
I find myself thinking about this too from time to time, but I trust them for at least basic reviews enough… I’m a perfectionist tho, so you can see me blame myself if I see one of my older ebuilds doing something I now think is silly or useless. That’s why I usually always edit ebuilds provided by users when I add them to portage. If it’s just style, I don’t pay much attention to it, if it’s something I think should be better done another way, I tell that to the contributor (but I’ll return on this later).
So, one thing that might help the Sunrise people there could be finding a developer that is well considered in Gentoo and ask him to join the reviewers, or to simply ask him when they aren’t entirely sure about something. I can’t help on a stable basis, mostly because of my missing free time, but I sure can point people to related examples and documentation. I’m sure there are other developers interested in Sunrise that will be pleased to help, aren’t there?
Maybe I haven’t hit the problem entirely, but I’m sure that at least for a few devs the reasons to not like Sunrise are the one I just said, hurting as they can be. Explicating them might have prevented wasting lot of time. Stuff like “I don’t like you”, although hard to say, and with the risk of hurting someone, has to be said sometimes, as it allows to move the problems from the technical level where they don’t belong, to the proper personal level.
Now, let’s return on the thing I left lingering before, about telling the contributors the reasons for changes. There are unfortunately a lot of bad examples of ebuilds in the tree. I can name for instance the old korilla and lush ebuilds, that to install some icons inherited kde eclass and installed in KDE’s prefix. Telling users what you change for compliance with QA or style standards is not a waste of time: they can learn from that and they’ll know what to do next time. I always do this way, so that I can count on them knowing what to do the time after. The answer “that is wrong” without telling what is wrong in it is a waste of time instead, because helps nobody. Sure, things has to be documented. If I didn’t document the reasons to use —as-needed, the reasons why packages breaks, and how to solve the most common breakages, for sure there wouldn’t be so much of the tree working fine when using it.
And now, to complete this long long blog, I want to talk about another thing that will help on the long term for sure. tcort shown on gentoo-dev mailing list his concerns about those people who decides to stop working on something after a while. This is an actual problem, but of course you cannot force anybody to continue maintaining something he doesn’t use anymore for instance. I did already propose a solution to this before, but people seemed not to like it because, well, it involved actual work and less pointless discussions, I suppose. My solution to that problem is writing specific maintainers’ guides for the packages. For instance I wrote xine maintainer’s guide, vlc maintainer’s guide and ALSA maintainer’s guide. They explain the quirks of the ebuilds, the reason why some choices have being made, why some useflags aren’t present while others are, and so on. If I did choose to leave Gentoo for good (don’t worry, won’t happen too soon, I hope), whoever wanted to take over xine or vlc could just take a look to those guides, see what the problems are and the current implemented solutions and that is. Yeah there might be space to documenting stuff inside the ebuilds themselves, but at least for those three, there is a lot of background one cannot really document in a single ebuild without increasing its size of 100% or 200%.
So a solution to the disappearing people problem is to ask people to document what they do and why, this will be used as future reference when needed. Even my blog, for me, is a reference of why I did something in a way rather than another, that’s why I often point people to my posts, as they are sometimes good documentation on stuff, just because I felt like talking of that problem or that fix or that improvement.
Unfortunately, the tendency is not to document enough 🙁
