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 |