1 |
On Wed, Aug 02, 2006 at 02:24:17AM +0200, Carsten Lohrke wrote: |
2 |
> On Monday 31 July 2006 07:05, Seemant Kulleen wrote: |
3 |
> > OK, let's start with: what exactly is the problem? |
4 |
> 1) Please reread my replies in the first sunrise thread. Points are: |
5 |
1) no security, |
6 |
|
7 |
Suggest you read their responses, and look into some of their material |
8 |
(in particular their faq). |
9 |
|
10 |
Two levels. |
11 |
|
12 |
One, holding area (essentially). |
13 |
Second level (what users get), is the reviewed branch. |
14 |
|
15 |
So... if you're arguing people can stick malicious shit into the first |
16 |
level, yes, they could. |
17 |
|
18 |
I could also stick malicious code into bugzilla. If you're dumb |
19 |
enough to run it without checking it, your own fault (both cases). |
20 |
|
21 |
If you're arguing that malicious code gets stuck into reviewed... when |
22 |
I was a dev, I could have very easily done the same thing. |
23 |
|
24 |
Comes down to trust that they know what they're doing for the second |
25 |
level- again, same situation for the gentoo-x86. |
26 |
|
27 |
And... just cause I'm mildly sick of this bullshit, I'll head off |
28 |
the retort of "but people with +w for gentoo-x86 have been passed |
29 |
through the developer process, screening the malicious". Ayone |
30 |
determined can punch through it without issue- *both* gentoo-x86 and |
31 |
sunrise. |
32 |
|
33 |
|
34 |
> 2) issues with eclass changes which will result in bug spam |
35 |
|
36 |
You're not supposed to change the exposed api of eclasses in the tree |
37 |
(something y'all do violate I might add, which is a seperate QA |
38 |
matter). Same issue applies to the 'official' overlays offered by |
39 |
devs also, and to the tree in general. |
40 |
|
41 |
It's a reaching statement, bluntly. Using such an arguement has the |
42 |
side affect of stating that no overlays should ever exist, because |
43 |
they suffer the same potentials. |
44 |
|
45 |
Which obviously is a bit of BS. |
46 |
|
47 |
|
48 |
> 3) the fact that sunrise is a bunch of arbitrary packages, instead close related ones managed |
49 |
> by one team, that does exactly maintain relevant packages. |
50 |
|
51 |
What the hell do you think the tree is? It's a bunch of arbitrary |
52 |
packages maintained loosely by subgroups of people; you're stating |
53 |
that sunrise is too loose yet gentoo-x86 is fundamentally no |
54 |
different. |
55 |
|
56 |
Sunrise is pretty much the same damn thing. |
57 |
|
58 |
|
59 |
> These issues are |
60 |
> fundamental, pointed out multiple times. You can't believe how ridiculous |
61 |
> Mike's question in the other thread, if there were any remaining issues, |
62 |
> sound to me and obviously others. |
63 |
|
64 |
Frankly, your points are assine/fud here. If you're going to bitch |
65 |
about flaws inherent in the work _you_ also do, kindly at least state |
66 |
it's universal rather then pawning it off as a sunrise specific |
67 |
failing. |
68 |
|
69 |
~harring |