Gentoo Archives: gentoo-dev

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

Replies

Subject Author
Re: [gentoo-dev] Re: culture clash (was: Ebuild Janitor Project) Luke Graham <luke@×××××××××.com>