Gentoo Archives: gentoo-dev

From: Luke Graham <luke@×××××××××.com>
To: gentoo-dev@g.o
Subject: Re: [gentoo-dev] Re: culture clash (was: Ebuild Janitor Project)
Date: Wed, 14 May 2003 01:45:47
In Reply to: [gentoo-dev] Re: culture clash (was: Ebuild Janitor Project) by Zach Welch
Mate, he just wants to tidy up some ebuilds and submit them to bugzilla. Stop 
talking rubbish about herds and culture. Sorry for the top post, but the 
message below is so bloody long.

On Wed, 14 May 2003 09:31 am, Zach Welch wrote:
> David Nielsen wrote: > > I announce a project and suddenly I'm the antichrist. > > Your not discussing it with any developers makes it an issue. You and > everyone else that would come along and say "we're doing it this way" > without having so much as consulted with the existing developers makes > that label not so undeserving. Your project itself is not at fault. > > I deservedly wore that same label once for these exact same reasons. > > > I did not treated to fork portage anywhere - I can't even code python > > for crying out loud. > > That's not the point -- the initial reaction to your side-stepping the > development team tends to be, like most human reactions, fairly > predictable: fight or flight. More generally and narcissticly: if you're > not with us, then you're against us. > > This is not technical reality I am talking about. This is all about > political and social perceptions - a reality that you will eventually > acknowledge even if simply by failing to over time. > > > Okay, the main issue seems to be getting along with developers. > > The developers come and go -- you must fit with the culture. There is a > big difference, and only the daily interactions make it seem otherwise. > Have no doubt -- no single individual within the Gentoo Linux community > is so important that the project can't survive without them, myself > fully included. > > > Here's a little background, I have Tourette' syndrome and I'm on > > antidepressants following an attempt at taking my life, bare with me > > I have a short fuse - I take shit all day. > > You are not the only person involved with this project that can make a > similar claim. I am very sympathetic to such circumstances, and > certainly it helps frame my interactions with individuals. However, in > the end: it does not matter. Disruptive behaviour eventually leads to > individuals being driven out of a social group because of its impact on > others, not the reasons that may or may not motivate it. > > These are problems that each of us must control; if you are 'off' on a > given day, then don't turn the computer on. I have learned firsthand > that if you can't control your interactions, you are signing your own > pink slip in this organization. > > Having suffered this briefly, I can imagine no greater social punishment > that can be leveled against its individuals than to permanently cast > them out from a group to which they want to belong. For extreme cases, > we call that "prison", and there can be no worse place for a person that > still feels the human need to be part of the surrounding society. > > If you want to be a member of any society, you simply cannot egregiously > or continually behave outside established cultural norms - or you will > go to jail, you will not pass GO, and you will not collect $200.00. > > > Here's what makes me happy, getting good ideas, and this project > > seemed like a good idea - So I took a chance, I never expected the > > project to take off the way it did, I figured I would fix up a few > > critical ebuilds a week and submit them to Bugzilla. It seems we need > > a quicker solution without compromising the stability of portage as > > a whole - we don't want broken shit in there do we? > > What "critical" ebuilds are not already in portage? Adding more packages > to the tree is not my idea of critical. Maintaining what we already have > should be higher priority. If you're really worried about things > being broken, you'll take a look at ways to help us improve our existing > QA situation without throwing more ebuilds to the fire. That pretty > much means working through the existing bugs already in Bugzilla, and > working with Bugzilla for managing submissions of fixes and patches. > > In any event, I say again - I am fully behind your ideas *in theory*, > possibly even before you were considering them: > > > > In fact, some of the herds ideas tossed around lately are echos of the > exact same I issues that I pressed too hard and resulting in my first > pink slip. I was right in my solutions -- completely wrong in both their > timing and presentation. I know I could still get myself "fired" again > by pressing too hard on similarly premature issues, have no doubt. > > We are still talking only theory with the ideas of Udder and herds > even today. The implementation is slowly creeping into existence, and > there is nothing anyone (not even myself) can do to hurry it along any > faster than it is already moving. Too many chefs spoil the soup. > > On the other hand, you have essentially proposed to spend your time and > resources maintaing your own forums, trees, etc. Instead, you might > consider that your ideas' time has not quite yet come, focusing your > efforts with helping us within the larger context that we have already > started to try and achieve. > > When the timing is right, your ideas can be made to flourish - but you > must also accept that the community process will transform them into > something that resembles, yet may prove to be vastly different, than > what you started out doing. Of course, we must all be willing to make > these compromises along the way, both technically and socially. > > Such is life. > > > We plan to release a tarball once a week with new ebuilds, now we are > > not asking for them to just go directly into portage, so there needs > > to be some developer review time going on also if possible - we also > > wanna make sure we waste as little time as possible right? > > Collecting ebuilds is not the problem. If you want this to work, users > must be doing all of the QA steps, wrapping their results up in an > automated report form that the developers can verify locally. And this > goes back to the key point, there must be *trust* between the users > doing this work and the developers maintaining the tree. > > For example, I would happily install an ebuild from certain developser > without even looking inside it. Needless to say, I am not so cavalier > about packages I received from Bugzila. I have yet to see my first > trojaned submission, but that's not for lack of looking. I must be able > to trust the submitter to have gone to the same lengths I do before I > will trust their ebuilds. > > Further, many submissions come with absolutely no quantitaive > information as to why it should be trusted. Most ebuilds are drastically > undercommented, insufficiently protected against failures, and lacking a > general feeling of having been "engineered". An innocuous looking > statement like rm -rf "${A}/${B}" can not be let slip out the door if > there is a chance that A and B could both be left unset. And that is not > a hypothetical situation - these events have happened. > > Even if an ebuild or patch looks well-engineered, I will not trust > someone's changes simply because they claim it fixes a problem: I must > also comprehend what that patch is doing only to the exent that I am > personally unfamiliar with the source. Anonymous submissions require my > full comprehension. > > The real solution to these problem is improving the order, structure, > and efficiency of communications. If we could all get together, learn to > trust one another, the world would be a better place. And since that's > not likely to anytime happen soon, let's work together with what we do > have and struggle (yes it will be a struggle) forward toward those > distant goals. > > When submitters and developers meet in IRC and bridge the gap, problems > can get solved very, very fast. While adequate, e-mail is a very big > step away from this level of interaction, and the current web-based > systems offer only shreds of back-end integration I want to see us have > someday. Personally, I loath the web forums and will not go near them > when I can help it, but that should not shut me out from what is > happening there -- we need an infrastructure that unites us together, > not yet another forum that fragments our resources. > > > In the end, I encourage you to do whatever you want to do, but do not > expect Gentoo developers to do anything for you until you manage to fit > into the existing culture. If you're not working with the group, you > have effectively forked yourself - even if that was not your intention. > Setting up a new forum is not playing in the existing culture, and I > personally consider it borderline unethical to be advertising it using > "legitimate" Gentoo resources. > > Now all that said, I would love to see your group to propose a plan that > can be supported within our existing culture. I, for one, am truly > joyful to see a group of users willing to step up to this enourmous > challenge, but simultaneously challenging the surrounding culture makes > the result problems nearly intractable. There are enough technical > issues to keep us busy without having to deal with social volatility at > the same time. > > > Please come talk to us on IRC to resolve these things; for those of you > that haven't caught on, that medium might just be the singularly most > effective catalyst for change in this project. In fact, I have the > #gentoo-udder channel was set up precisely to help us resolve these issues. > > Cheers, > > Zach Welch > Superlucidity Services > > > -- > gentoo-dev@g.o mailing list
-- luke@×××××××××.com Fax: +47 21604801 Trolltech AS, Waldemar Thranes gt. 98, N-0175 Oslo, Norway -- gentoo-dev@g.o mailing list


Subject Author
Re: [gentoo-dev] Re: culture clash (was: Ebuild Janitor Project) David Nielsen <Lovechild@××××××××.com>