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
Message-Id: 200305141142.57728.luke@trolltech.com
In Reply to: [gentoo-dev] Re: culture clash (was: Ebuild Janitor Project) by Zach Welch
1 Mate, he just wants to tidy up some ebuilds and submit them to bugzilla. Stop
2 talking rubbish about herds and culture. Sorry for the top post, but the
3 message below is so bloody long.
4
5 On Wed, 14 May 2003 09:31 am, Zach Welch wrote:
6 > David Nielsen wrote:
7 > > I announce a project and suddenly I'm the antichrist.
8 >
9 > Your not discussing it with any developers makes it an issue. You and
10 > everyone else that would come along and say "we're doing it this way"
11 > without having so much as consulted with the existing developers makes
12 > that label not so undeserving. Your project itself is not at fault.
13 >
14 > I deservedly wore that same label once for these exact same reasons.
15 >
16 > > I did not treated to fork portage anywhere - I can't even code python
17 > > for crying out loud.
18 >
19 > That's not the point -- the initial reaction to your side-stepping the
20 > development team tends to be, like most human reactions, fairly
21 > predictable: fight or flight. More generally and narcissticly: if you're
22 > not with us, then you're against us.
23 >
24 > This is not technical reality I am talking about. This is all about
25 > political and social perceptions - a reality that you will eventually
26 > acknowledge even if simply by failing to over time.
27 >
28 > > Okay, the main issue seems to be getting along with developers.
29 >
30 > The developers come and go -- you must fit with the culture. There is a
31 > big difference, and only the daily interactions make it seem otherwise.
32 > Have no doubt -- no single individual within the Gentoo Linux community
33 > is so important that the project can't survive without them, myself
34 > fully included.
35 >
36 > > Here's a little background, I have Tourette' syndrome and I'm on
37 > > antidepressants following an attempt at taking my life, bare with me
38 > > I have a short fuse - I take shit all day.
39 >
40 > You are not the only person involved with this project that can make a
41 > similar claim. I am very sympathetic to such circumstances, and
42 > certainly it helps frame my interactions with individuals. However, in
43 > the end: it does not matter. Disruptive behaviour eventually leads to
44 > individuals being driven out of a social group because of its impact on
45 > others, not the reasons that may or may not motivate it.
46 >
47 > These are problems that each of us must control; if you are 'off' on a
48 > given day, then don't turn the computer on. I have learned firsthand
49 > that if you can't control your interactions, you are signing your own
50 > pink slip in this organization.
51 >
52 > Having suffered this briefly, I can imagine no greater social punishment
53 > that can be leveled against its individuals than to permanently cast
54 > them out from a group to which they want to belong. For extreme cases,
55 > we call that "prison", and there can be no worse place for a person that
56 > still feels the human need to be part of the surrounding society.
57 >
58 > If you want to be a member of any society, you simply cannot egregiously
59 > or continually behave outside established cultural norms - or you will
60 > go to jail, you will not pass GO, and you will not collect $200.00.
61 >
62 > > Here's what makes me happy, getting good ideas, and this project
63 > > seemed like a good idea - So I took a chance, I never expected the
64 > > project to take off the way it did, I figured I would fix up a few
65 > > critical ebuilds a week and submit them to Bugzilla. It seems we need
66 > > a quicker solution without compromising the stability of portage as
67 > > a whole - we don't want broken shit in there do we?
68 >
69 > What "critical" ebuilds are not already in portage? Adding more packages
70 > to the tree is not my idea of critical. Maintaining what we already have
71 > should be higher priority. If you're really worried about things
72 > being broken, you'll take a look at ways to help us improve our existing
73 > QA situation without throwing more ebuilds to the fire. That pretty
74 > much means working through the existing bugs already in Bugzilla, and
75 > working with Bugzilla for managing submissions of fixes and patches.
76 >
77 > In any event, I say again - I am fully behind your ideas *in theory*,
78 > possibly even before you were considering them:
79 >
80 > http://cvs.gentoo.org/~zwelch/udder/
81 >
82 > In fact, some of the herds ideas tossed around lately are echos of the
83 > exact same I issues that I pressed too hard and resulting in my first
84 > pink slip. I was right in my solutions -- completely wrong in both their
85 > timing and presentation. I know I could still get myself "fired" again
86 > by pressing too hard on similarly premature issues, have no doubt.
87 >
88 > We are still talking only theory with the ideas of Udder and herds
89 > even today. The implementation is slowly creeping into existence, and
90 > there is nothing anyone (not even myself) can do to hurry it along any
91 > faster than it is already moving. Too many chefs spoil the soup.
92 >
93 > On the other hand, you have essentially proposed to spend your time and
94 > resources maintaing your own forums, trees, etc. Instead, you might
95 > consider that your ideas' time has not quite yet come, focusing your
96 > efforts with helping us within the larger context that we have already
97 > started to try and achieve.
98 >
99 > When the timing is right, your ideas can be made to flourish - but you
100 > must also accept that the community process will transform them into
101 > something that resembles, yet may prove to be vastly different, than
102 > what you started out doing. Of course, we must all be willing to make
103 > these compromises along the way, both technically and socially.
104 >
105 > Such is life.
106 >
107 > > We plan to release a tarball once a week with new ebuilds, now we are
108 > > not asking for them to just go directly into portage, so there needs
109 > > to be some developer review time going on also if possible - we also
110 > > wanna make sure we waste as little time as possible right?
111 >
112 > Collecting ebuilds is not the problem. If you want this to work, users
113 > must be doing all of the QA steps, wrapping their results up in an
114 > automated report form that the developers can verify locally. And this
115 > goes back to the key point, there must be *trust* between the users
116 > doing this work and the developers maintaining the tree.
117 >
118 > For example, I would happily install an ebuild from certain developser
119 > without even looking inside it. Needless to say, I am not so cavalier
120 > about packages I received from Bugzila. I have yet to see my first
121 > trojaned submission, but that's not for lack of looking. I must be able
122 > to trust the submitter to have gone to the same lengths I do before I
123 > will trust their ebuilds.
124 >
125 > Further, many submissions come with absolutely no quantitaive
126 > information as to why it should be trusted. Most ebuilds are drastically
127 > undercommented, insufficiently protected against failures, and lacking a
128 > general feeling of having been "engineered". An innocuous looking
129 > statement like rm -rf "${A}/${B}" can not be let slip out the door if
130 > there is a chance that A and B could both be left unset. And that is not
131 > a hypothetical situation - these events have happened.
132 >
133 > Even if an ebuild or patch looks well-engineered, I will not trust
134 > someone's changes simply because they claim it fixes a problem: I must
135 > also comprehend what that patch is doing only to the exent that I am
136 > personally unfamiliar with the source. Anonymous submissions require my
137 > full comprehension.
138 >
139 > The real solution to these problem is improving the order, structure,
140 > and efficiency of communications. If we could all get together, learn to
141 > trust one another, the world would be a better place. And since that's
142 > not likely to anytime happen soon, let's work together with what we do
143 > have and struggle (yes it will be a struggle) forward toward those
144 > distant goals.
145 >
146 > When submitters and developers meet in IRC and bridge the gap, problems
147 > can get solved very, very fast. While adequate, e-mail is a very big
148 > step away from this level of interaction, and the current web-based
149 > systems offer only shreds of back-end integration I want to see us have
150 > someday. Personally, I loath the web forums and will not go near them
151 > when I can help it, but that should not shut me out from what is
152 > happening there -- we need an infrastructure that unites us together,
153 > not yet another forum that fragments our resources.
154 >
155 >
156 > In the end, I encourage you to do whatever you want to do, but do not
157 > expect Gentoo developers to do anything for you until you manage to fit
158 > into the existing culture. If you're not working with the group, you
159 > have effectively forked yourself - even if that was not your intention.
160 > Setting up a new forum is not playing in the existing culture, and I
161 > personally consider it borderline unethical to be advertising it using
162 > "legitimate" Gentoo resources.
163 >
164 > Now all that said, I would love to see your group to propose a plan that
165 > can be supported within our existing culture. I, for one, am truly
166 > joyful to see a group of users willing to step up to this enourmous
167 > challenge, but simultaneously challenging the surrounding culture makes
168 > the result problems nearly intractable. There are enough technical
169 > issues to keep us busy without having to deal with social volatility at
170 > the same time.
171 >
172 >
173 > Please come talk to us on IRC to resolve these things; for those of you
174 > that haven't caught on, that medium might just be the singularly most
175 > effective catalyst for change in this project. In fact, I have the
176 > #gentoo-udder channel was set up precisely to help us resolve these issues.
177 >
178 > Cheers,
179 >
180 > Zach Welch
181 > Superlucidity Services
182 >
183 >
184 > --
185 > gentoo-dev@g.o mailing list
186
187 --
188 luke@×××××××××.com Fax: +47 21604801
189 Trolltech AS, Waldemar Thranes gt. 98, N-0175 Oslo, Norway
190
191 --
192 gentoo-dev@g.o mailing list

Replies

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