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 |