So why should we try to make them happy at all?
So, let’s see bug #196926. It’s a nasty bug in glibc, somehow it lapsed through the quality checks for glibc releases, and it hits the two major architectures that Gentoo supports (x86 and amd64, or rather multilib amd64, as the failure is still related to the x86 codepaths; amd64-only codepaths are just fine); on the lucky side, the problem only presents itself when glibc-omitfp is enabled, and it is not by default for sure.
There is a tentative patch; sure there is, there are for most bugs, sometimes they are not just enough. And you don’t really want to risk with glibc. Plus, Mike who takes care of most toolchain, glibc included, is quite busy, and having him release new patchsets every day to fix issues that are caused by non default setups would require him to spend all his time on tar and epatching around.
Okay, maybe sometimes Mike has the prerogative of not creating new patchsets until he has a trouble with the current patchset, that’s why I continue insisting fo him to release a new GCC patchset to fix the failures building htdig and xalan-c. But as I know the kind of burden that releasing a new GCC is, and let’s not even try to make the burden of releasing a new glibc something that can be explained in a single blog post.
Anyway, as I know the particular traits of Mike’s character, I decided to take action myself. As I certainly have no time to start testing new patches to glibc all over, and I know that messing with someone else’s package patches can create more troubles to that person, I avoided the patch altogether, but I decided to mask the glibc-omitfp USE flag. It’s still better than nothing: users upgrading will get a working glibc, maybe not with the frame pointer omitted, but they won’t find strange failures and won’t make me waste time finding new mails with “me too” comments – sorry, we do know that there is a problem, after three people said so, and the developers acknowledged it, saying “me too” just annoys the hell out of the people that are in CC on the bug to follow the development of it – plus, I know that Mike wouldn’t have been upset by my masking.
But hey, this is not enough for some users. And that is what sometimes frustrates me. Trying to help them to get a working package is not enough, it has to be the package as they want entirely; no more and no less!
Well, I would like to let those users know that Gentoo is a volunteers-based distribution. And some volunteers are already doing stuff they care little about personally, just for the greater good of having the distribution working. Lately, though, some of them, some people I actually find important in the whole Gentoo microcosm, start to be frustrated, seeing users that demand stuff to be like they want, and developers that rarely support their decision, and just criticise.
For many of us, Gentoo is about fun; I’m one of them, I always was one of them because I do find fun maintaining some easy ebuilds, I do find fun being able to integrate anew software that might be useful to me and others into the distribution, and I sometimes do find fun having to dive into the internals of a software to fix a bug, or to make the build system behave like a good build system should.
I certainly don’t find fun in having users demanding that their solution be implemented immediately, nor I do have fun in people repeatedly sending “me too” messages that just waste my time, and least of all I have fun in seeing developers fighting with each other over nothing, because they are all stressed both from the work they have to do (often Gentoo for us is a second job, or a part-time job, or an hobby), upstreams that might not be very nice to deal with, and by users who demand that everything be perfect.
To sum it up, for what concerns glibc 2.7, the USE flag is masked in amd64 and x86 profiles; I could have unmasked it for no-multilib profiles for amd64 actually, but I didn’t care yet enough for that; people not using multilib on amd64 would probably be able to unmask it manually anyway. I didn’t follow if the upstream sources of glibc were patched and thus fixed, but I hope they did, for that case, I limited the mask to 2.7 version of glibc, so a new version of glibc will not have glibc-omitfp masked. If Mike commits a new glibc patchset with the patch, he’ll probably drop the USE flag, or I’ll do it, so the masking won’t stay more than needed, it’s just a matter of having the build not fail on users.
To my fellow developers, I would say instead: “try to let it go the hatred”. Yes, I know that there are developers who act in ways getting on your nerves (and pay attention, I’m not referring to anyone in particular; I actually can think of about four people that do appear in both roles with different combinations), I know you’d rather have things done in another way, but unless you can replace them, you shouldn’t make it your own battle to find them wrong every turn of the road.
People have different ways of thinking and different ways of doing their job. Even if you disagree on a technical or social level, it doesn’t mean you can’t try to respect each other and try to understand the point of view of the other person. I can actually say that after about two and a half years, some of the developers I respect most (and I consider friends, and love to work with) are developers with whom I rarely share views; just to drop some names (that you can confirm on mailing lists or if you really want to read #gentoo-dev), there are Donnie and solar. With the former we have very much opposite views about technical progress versus compatibility (and you can easily find this out by looking at the long discussions we had about Xorg and FreeBSD), but I find him a very skilled developer and also a nice person, and I was thrilled when I seen that we ended up in the council together this term; for what concerns Ned, we had quite some arguing about FreeBSD, uClibc, and NLS support, again we have opposite views, but this might help and we usually get to find a compromise solution that suits more or less both of us, and I do call him “friend”.
Okay so the post turned out to be concerning both users and developers behaviour, I actually didn’t intend that much when I started, I just wanted to write something to clarify the masking of glibc, and to say which kind of behaviour won’t bring you in my list of good users. And only people in that list will get their Christmas present… (read: if you’re an user I don’t have a problem with, I might answer to your bugs even during the holidays).
I think you were right to post this. Seeing the way things unfolded in that bug really pissed me off. Quite frankly, I have no idea what the difference is between omitfp glibc and a non-omitfp glibc, so it doesn’t really bother me that it was masked. Speaking of which … what is the difference and what is the advantage? I think users are complaining over a point that means nothing in the end.
the FLOSS world is build upon a fragile ground. If users start treating developers like a boss that is paying for an employees time, then demotivation can occur. And if developers interaction because hostile, then demotivation can occur. The solutions to fix these two problems are very important to the health of the FLOSS world. From my skimming, Gentoo has something called a “developer relations” board that address some issue. Debian has a tech-ctte to address dev-to-dev technical disagreements and is trying to create a social-ctte to address ‘bad blood’ amongst devs escalating because of a few incidents that lead to folks being removed. Finding a solution to nip social problems ‘in the bud’ as they occur, to prevent real feuds or removal is something that the FLOSS world needs desperately and hopefully some academic can do research to find an approach that is non-obvious.As for users, they have to be made aware of what they can expect from FLOSS devs and if they want an issue escalated to a level beyond what a dev will/can do, they need to be told where to find that level of support which would lead to someone being paid. Right now, Ubuntu has Canonical. Other distros need something like this or maybe Canonical can hire other distro specialists to aggreate support under one roof and allow more choice.
First, Diego, a big THANK YOU for all the work you, and of course the other devs, do for Gentoo and that I benefit from.Second to the users: I always assumed ~x86 is for testing and bugs can and will come up. A bug report was filed, a work-around was proposed and implemented. That should be sufficient. Business as usual. Why all the fight? glibc 2.7 will not go stable before that bug is finally fixed.Last but not least to all the Gentoo developers: Don’t feed the trolls. Don’t react to “Me too” messages. Don’t accept the artificial pressure that some try to put on you. Be a little more laid back. You are neither boss nor subordinate. Then we hopefully will see less developers leave the project in the future.We should all try to contribute. Some can do more, some less.
If a user can make an actual case for doing something in a particular way, fine. But if a user is just making demands, I’d love to see devs do a more thorough job of ignoring that user. Getting worked up about a vocal handful of users making demands is a waste of time and energy.
Nice post, thanks; wrt to “a user [making] an actual case for doing something in a particular way” that’s not really enough. If they don’t have the technical skills to implement it, they should project manage the people they know personally who do. Inspiration is only 1% of the job, and Free software needs people who can do.Otherwise it’s just a case of too many cooks, imo.
“Project manage,” steveL, seriously? Not if you’re not invited to project manage a developer. In fact, this whole post is about non-skilled people project managing developers. Now, if you want to play a role in pro*duct* management, then that’s different — and even then, you can’t just step up and presume to manage people without their consent, and certainly not by just coming in and making demands.No, there are ways of dealing with the kind of people who give away their time to improve the overall user experience. And it starts with “respect” not “management”.
Er I meant help others to do their work Seemant, and note I said “people” not devs. IOW If you want something done, help to get it done.I never said come in and project manage devs, and never would. That’s also why I restricted it to “people they know personally,” ie get together with your friends and start working on something, rather than just randomly throwing out ideas; which is when it becomes a case of too many cooks.I thought that was clear, obviously it wasn’t as explicit as it could be. Sorry for your confusion.Many people feel they can’t help because they are not skilled technically. Firstly (and I think too many forget this) no-one was when they started out, and secondly there’s a whole lot more to software development than coding.