1 |
On Fri, 2006-06-09 at 12:20 -0400, Chris Gianelloni wrote: |
2 |
> > bugzilla sucks. Ever had to download 10 attachments for one ebuild? |
3 |
> > It is a good tool for discussion, but I would prefer a simple tool (like |
4 |
> > layman) that can automatically update things. You obviously don't like |
5 |
> > overlays, but that shouldn't be a reason to stop us from using it. |
6 |
> |
7 |
> Well, I thank you for your vast experience as an ebuild developer in |
8 |
> this matter. |
9 |
|
10 |
My pleasure. I'd rather see myself as poweruser in this regard since I |
11 |
try not to break too many ebuilds ... |
12 |
|
13 |
> You do realize that this isn't one of those things where you can say |
14 |
> that if you don't like it you don't have to use it, right? |
15 |
> |
16 |
> This *will* affect *every* ebuild developer. |
17 |
Maybe you don't realize that taking ebuilds for packages that are _not in portage_ and providing them in a nice bundle does not affect every developer? |
18 |
Noone wants to push a new cvs-snapshot of glibc. That so not the point |
19 |
here. |
20 |
|
21 |
But having a controlled managed overlay with ebuilds that are now spread |
22 |
all across bugzilla ... that would be a good service to our users. |
23 |
|
24 |
> This means it *CANNOT* be left up to a small group of developers to |
25 |
> decide without any discussion on the matter. |
26 |
So now we're a democracy where everything needs to be voted upon? |
27 |
*sigh* |
28 |
Let's leave that debate for another day ... |
29 |
|
30 |
> > Yes, now it is easier to check out the ebuilds. More users ==> better |
31 |
> > testing. |
32 |
> |
33 |
> Except that now the developer has to do much more work to get the same |
34 |
> information, making it even less likely that he'll bother to pick up one |
35 |
> of these maintainer-wanted bugs. |
36 |
s/the developer/I/ |
37 |
there are some devs that would prefer this overlay environment. |
38 |
Please don't push your personal preferences as The Right Way (tm) |
39 |
|
40 |
> You also completely gloss over the |
41 |
> ability of a single rogue user to now compromise countless users with a |
42 |
> single commit. |
43 |
And an ebuild on bugzilla has more security? |
44 |
We're just making it easier to use these ebuilds. Also I expect the |
45 |
maintainers to keep a reasonable quality standard. |
46 |
> Please come back once you've firmly grounded yourself in |
47 |
> the reality that we're a pretty popular distribution, and that makes |
48 |
> this project a prime target for malicious abuse. Perhaps if you were |
49 |
> responsible for some ebuilds, you've be more cognizant of the |
50 |
> implications that a bad commit can cause our users. |
51 |
I am not responsible for ebuilds because I don't trust myself enough :-) |
52 |
That doesn't stop me from giving out access to my server to anyone who |
53 |
has a good reason ... like the Gentoo/HURD repository or the Java |
54 |
overlay. |
55 |
|
56 |
> > That differs from the 20 or so overlays maintained by users how? |
57 |
> |
58 |
> Let's see. They aren't on Gentoo infrastructure, which means they don't |
59 |
> give off any immediate assumption of being "official" or "supported" in |
60 |
> any way. Hell, go back and look at Peter's response about how he would |
61 |
> use an overlay such as this only *because* it is on Gentoo |
62 |
> infrastructure. |
63 |
> |
64 |
> So what exactly was your counter-point again? |
65 |
We have control over sunrise. And hey, if it sucks kill the project with silver bullets, a stake to the heart and two pounds of garlic. |
66 |
Just don't kill an idea before it is even tested ... |
67 |
|
68 |
> Having an overlay such as this will tarnish Gentoo's reputation. |
69 |
No :-) |
70 |
What reputation are we talking about? The distro that lags in updates |
71 |
behind others? |
72 |
Where you see a problem I see potential: More well-tested ebuilds, |
73 |
recruiting potential developers ... if you don't want that you're an |
74 |
elitist bastard. ;-) |
75 |
|
76 |
> We |
77 |
> should not be providing *anything* that is only half-supported or |
78 |
> half-tested. Anything less than being sully supported via the security |
79 |
> team and QA is a failure on the part of Gentoo. We have enough *crap* |
80 |
> in the *tree* that is unsupported, which makes us look bad, yet you want |
81 |
> to insist on supporting a project that affects all of the ebuild |
82 |
> developers, which you have not mentioned is a group which you are not a |
83 |
> part of, so can gladly speak of increasing their workload with no |
84 |
> consequences to yourself, and provides an avenue for low-quality or |
85 |
> possibly malicious ebuilds to be distributed to our users, all under a |
86 |
> Gentoo banner? |
87 |
No :-) |
88 |
1) It doesn't increase your workload - these packages are things that |
89 |
are _not_ in the main tree. |
90 |
No overlap --> no stupid bugs with overwritten ebuilds etc. |
91 |
2) low-quality? I might mention that I'm hosting some overlays that have |
92 |
non-gentoo contributors (*gasp!*) |
93 |
Why are they hosted on my server? Because the contributors are not (yet) |
94 |
gentoo devs, but provide good to excellent input to the projects. So now |
95 |
you tell me that I'm doing wrong in helping Gentoo development? These |
96 |
people can't contribute to other gentoo-hosted projects, so it is easier |
97 |
to move the repositories to a more liberal server. |
98 |
|
99 |
That tells me that Gentoo development is fundamentally buggy when we |
100 |
complain about a lack of manpower and then say "yeah, but not _that_ |
101 |
kind of manpower" when users try to help. |
102 |
|
103 |
<cynic> |
104 |
And people wonder why usually things get done secretly and then |
105 |
presented as a finished product - no wonder, it seems to be the only way |
106 |
to get _anything_ done. |
107 |
</cynic> |
108 |
|
109 |
> I seriously question your motives towards the Gentoo project. |
110 |
Good. Question them. I'm still doing what I can to help ... doing such silly things as finding new servers for Infra and writing articles for the GWN. |
111 |
If that isn't good enough ... well ... who cares. You invest as much as |
112 |
I do in your own server for Gentoo usage and I'll not question _your_ |
113 |
motives. |
114 |
|
115 |
> > Hmmm ... bugzilla. |
116 |
> > Instead of a simple cvs up; cd /usr/local/portage/category/package I |
117 |
> > need to search for ALL bugs with $name in it, look which one it is, |
118 |
> > curse bugzilla for falling asleep again, see which attachments are |
119 |
> > relevant, download them, curse bugzilla for falling asleep again, copy |
120 |
> > them to my overlay, read the bugcomments to see if any special renaming |
121 |
> > or directory structure is needed ... |
122 |
> > |
123 |
> > Hmmm. I think an overlay does have some advantages there ... |
124 |
> |
125 |
> Sure. Until I sneak in some obfuscated code as a "fix" to a "bug" and |
126 |
> it gets executed on your machine because the actual *developers* that |
127 |
> are used to maintaining this stuff and know what to look for aren't a |
128 |
> part of the process. |
129 |
It's all about trust. Those people that suck ebuilds out of bugzilla now |
130 |
will use the overlay. Same potential for damage in a slightly different |
131 |
package ... |
132 |
|
133 |
> Making something easier does not make it better. I'm sorry, but you've |
134 |
> yet to convince me on how your laziness is supposed to be an improvement |
135 |
> for the development process of Gentoo. |
136 |
Less work --> more time to do interesting things. |
137 |
|
138 |
And just because you don't like overlays doesn't mean we should remove |
139 |
them. Heck, I really really dislike Gnome, but I'm not going to petition |
140 |
for removal just because I don't like it. |
141 |
|
142 |
Remember that "Gentoo is all about choice" discussion that pops up every |
143 |
now and then? |
144 |
If a motivated group of devs wants to try an overlay experiment you |
145 |
should let them try. Worst case it's a failure and gets punted after two |
146 |
months. |
147 |
|
148 |
|
149 |
> Wow. Another one of those "I can't answer your issue, so I'll just try |
150 |
> to divert your attention somewhere else" answers. Thanks for absolutely |
151 |
> nothing but contributing noise. |
152 |
You know, I've met you at FOSDEM and I know that you don't mean this as an insult, but it is very easy to misread it as that. |
153 |
Might I suggest that you don't formulate responses in a way that can |
154 |
easily be read as a personal attack? |
155 |
|
156 |
> > > Wouldn't this process be *infinitely* easier if instead of "sunrise" |
157 |
> > > there was a "pam" overlay with *only* the pam stuff? |
158 |
> > Ooooh, cool. Now I need about 75 overlays to get things done, and of course there will be no bad interaction between them ;-) |
159 |
> As opposed to the free for all that is this overlay? |
160 |
It's easier to manage one big overlay - at least that seems to be the motivation for doing it. |
161 |
And if we're all mistaken we at least learn a valuable lesson. |
162 |
|
163 |
> > Having one overlay with a focus on not-in-portage ebuilds should not |
164 |
> > cause the scenario you described and will most likely cause less weird |
165 |
> > bugs because of intra-overlay dependencies. |
166 |
> What evidence do you have of this? |
167 |
> > </opinion> |
168 |
It helps if you keep things in context |
169 |
|
170 |
> Oh, right. None. |
171 |
That's why I wrapped it in <opinion></opinion> tags. |
172 |
If we knew the answers we wouldn't need to discuss things ... |
173 |
|
174 |
|
175 |
> > ... and if we control the overlay we can exclude things like system |
176 |
> > packages easily. |
177 |
> |
178 |
> You really do a good job of making attempts to skirt the issues. Do me |
179 |
> a favor, if you're just going to use vague references and try to avoid |
180 |
> answering the issues at hand, don't bother wasting everyone's time by |
181 |
> replying. You're more than welcome to provide some *useful* insight, |
182 |
> but simply stating that something won't be an issue doesn't make it |
183 |
> true. |
184 |
And you are trying your best to make me look like an ass. Please stop |
185 |
doing that, it makes discussion really hard. Keep to technical issues. |
186 |
|
187 |
The issue is: This overlay will _not_ contain BreakMyGentoo-style |
188 |
ebuilds of new versions of things in portage. There won't be a glibc cvs |
189 |
snapshot. Just ebuilds that for now live in bugzilla and are hard to |
190 |
find. We wish to provide them in an easy-to-use package to our users. |
191 |
|
192 |
You know ... users. Those people that are not devs. Some of us try to |
193 |
give them the best experience we can, and if there is something like an |
194 |
overlay that even the more n00bish users can use we should try to |
195 |
provide it. |
196 |
|
197 |
> > Could be part of the policy to not touch existing ebuilds. |
198 |
> Actually, it already is, according to jokey. |
199 |
Even better! |
200 |
|
201 |
> > And again, one svn repo vs. 113 hard-to-find bugs ... |
202 |
> Amazing how you pull such numbers out of thin air. |
203 |
It's a special talent. 47 <-- just for you |
204 |
> Which 113 bugs are you talking about, exactly? |
205 |
Try to find the relevant files in the three bugs jakub posted. |
206 |
Now try that for multiple packages ... Most users won't need to harvest |
207 |
113 bugs, but I'd prefer a "svn up". It's just so much saner and less |
208 |
work that it is hard for me to see how bugzilla even makes sense. |
209 |
> > > Even better, if I am the proxy |
210 |
> > > maintainer for a particular set of ebuilds for one or more |
211 |
> > > user/maintainers, why do I need it in your big, bloated, and completely |
212 |
> > > inappropriately-named "sunshine" overlay versus a developer overlay of |
213 |
> > > my own? |
214 |
> > You don't. Please use your developer overlay. Please don't try to take |
215 |
> > away our more open overlay. |
216 |
> |
217 |
> Unfortunately, your request for my dropping of this issue will not be |
218 |
> honoured. |
219 |
That is weird, but you are entitled to your opinion. |
220 |
|
221 |
> This overlay is a bad idea, that is being poorly executed, |
222 |
> and is being *forced* on the developer community at large with |
223 |
> absolutely no for-warning or planning. |
224 |
That is your opinion. I think it's a good idea with a best-effort |
225 |
execution. |
226 |
And noone is forced to do anything - all that data is in bugzilla |
227 |
already. |
228 |
|
229 |
> It really is a shame that we |
230 |
> don't have any policies that allow for action to be taken against people |
231 |
> who either knowingly, or through actions of ignorance, cause massive |
232 |
> damage to Gentoo such as this. |
233 |
Define damage - I see your efforts to keep a motivated group of devs |
234 |
from implementing a new and untested idea as damaging. But I can accept |
235 |
that - you have a different point of view. Would be boring if we all |
236 |
agreed. |
237 |
|
238 |
> > > After all, I am the *only* proxy maintainer. Why should there |
239 |
> > > be the added *insecurity* of allowing any number of people that *I* |
240 |
> > > might not trust complete access to the small number of packages where I |
241 |
> > > am the proxy? |
242 |
> > It's your choice. Either you get mailbombed with each minor version update or you trust them to not screw up with the sunrise overlay. |
243 |
> |
244 |
> Isn't that what the process of becoming a developer is supposed to |
245 |
> build? |
246 |
That process that many people consider too complicated and |
247 |
time-consuming? |
248 |
Not everyone wants to spend 20h a week on Gentoo. Some people just want |
249 |
to maintain their personal app for Gentoo. In some cases we already have |
250 |
proxy-maintainers, so I don't see why we should not try to find more |
251 |
motivated smart users to help. |
252 |
|
253 |
> Also, just because I trust one person, doesn't mean I trust |
254 |
> someone that you trust. Trust is not implicit, it is earned. |
255 |
That's why most Gentoo devs can have an account on my server. Except |
256 |
those that have told me directly that they don't like me :-) |
257 |
|
258 |
> Some |
259 |
> random user having complete access to an area where only people that *I* |
260 |
> trust should really have access is not instilling faith in me of this |
261 |
> project. However, instead of answering these concerns, you simply brush |
262 |
> them aside as a non-issue, though I am not the only developer that has |
263 |
> spoken out on this *exact* same issue. |
264 |
The difference between a random user and a dev often is not much more |
265 |
than an @gentoo.org email adress. I don't consider all users |
266 |
untrustworthy - if they show that they wish to help we should not |
267 |
sabotage them. Maybe you don't remember the time when you were "just" a |
268 |
user? |
269 |
|
270 |
> Why exactly are we supporting these overlays via layman anyway? That |
271 |
> implies a level of trust and support that you admit we do not have. I |
272 |
> guess I should touch on that subject next, but that doesn't belong in |
273 |
> this discussion. |
274 |
We support them because a dev or a group of devs decided to do it. |
275 |
As long as Gentoo doesn't have a BDFL this will happen ... and if you |
276 |
don't like it discuss it with the relevant person(s). Maybe they are |
277 |
willing to change things? |
278 |
|
279 |
> > Maybe we even find some motivated new ebuild monkeys that have the |
280 |
> > motivation to become devs ... one can always hope :-) |
281 |
> |
282 |
> ...and maybe we get owned and people quit using Gentoo because a few |
283 |
> developers decided to go against the advice of other developers and |
284 |
> allowed for an easy-access, easily-exploitable way for some malicious |
285 |
> user to own countless Gentoo boxes, and nobody did anything to stop it. |
286 |
If someone wanted to exploit boxen he'd use a much simpler attack |
287 |
vector ... our rsync mirrors are wide open. No need to secure the little |
288 |
window over there when the front door is open ... |
289 |
|
290 |
> Well, I am going to do everything within my power to stop it. I will |
291 |
> not back down until this project is dead. It really is that simple. |
292 |
Ok, that seems counterproductive to me, but if you are not willing to compromise it will be hard to have any communication at all. |
293 |
|
294 |
Instead of trying to kill this idea you should try to get it modified |
295 |
into something we all can agree on. |
296 |
|
297 |
|
298 |
take care, |
299 |
Patrick |
300 |
-- |
301 |
Stand still, and let the rest of the universe move |