1 |
On Wed, Aug 02, 2006 at 10:27:04PM -0500, Lance Albertson wrote: |
2 |
> Brian Harring wrote: |
3 |
> > On Wed, Aug 02, 2006 at 08:05:15PM +0200, Carsten Lohrke wrote: |
4 |
> |
5 |
> >> Local overlays are fine as the user exactly knows what he does in his private |
6 |
> >> overlay (and hopefully follows eclass changes), development overlays are fine |
7 |
> >> (assuming the group of people controls the releavant overlays as well), |
8 |
> >> overlays like Sunrise are problematic, not to use such anal words as you do. |
9 |
> > |
10 |
> > Why are they problematic? Because of your assumption that they won't |
11 |
> > maintain it? |
12 |
> > |
13 |
> > It's the same thing as gentoo-x86 (I will keep stating that till it's |
14 |
> > grilled into peoples heads also), this is _not_ a new issue so why are |
15 |
> > people leveling issues of gentoo-x86 as new issues of sunrise? |
16 |
> > |
17 |
> > So someone goes and breaks something in gentoo-x86 that breaks |
18 |
> > something for sunrise. Fine, it's sunrises' mess to clean up; they've |
19 |
> > volunteered to do this work, I don't see how you can claim it as a |
20 |
> > negative when they've accepted it as part of _their_ work. |
21 |
> |
22 |
> I think the point a lot of people are concerned about are packages that |
23 |
> contain libraries or other dependencies that reside in the sunrise tree. |
24 |
> There's a good chance that a package in the regular tree will link |
25 |
> against a package from sunrise, the user will have no idea or forget |
26 |
> that they installed that app from sunrise (and the dep exists), and a |
27 |
> bug arises. |
28 |
|
29 |
http://www.gentoo-sunrise.org/sunrise/wiki/SunriseFaq |
30 |
|
31 |
Specifically, for those who haven't done their reading, look for the |
32 |
"Can I commit everything I like to the overlay", specifically the |
33 |
rules involved for what goes in. |
34 |
|
35 |
The short and skiny is that the arguement of "they'll have some |
36 |
package that breaks my package" is kind of daft- sunrise won't hold |
37 |
version bumps for packages in the tree (one exception to this is |
38 |
maintainer-needed that has sat, perhaps they can clarify that corner |
39 |
case). |
40 |
|
41 |
For the maintainer-wanted, the developer who pulls the package in |
42 |
*should* be lifting from sunrise already. Why? Because whats there |
43 |
has actually been exposed to users, rather then them relying on a |
44 |
simple eyeballing of the ebuild from bugzilla instead. |
45 |
|
46 |
That leaves the "will link against a package from sunrise"... covered |
47 |
the potentials above, the remaining case is a package in the tree |
48 |
linking against a maintainer-needed ebuild. |
49 |
|
50 |
Funny thing, that's actually a bug in the developers package. Daft I |
51 |
know, but it's actually a *good* thing to smoke those out, there |
52 |
should be no unstated linkage (if it ain't in the deps, it's |
53 |
a bug to use/link to it). |
54 |
|
55 |
|
56 |
> Who's fault is it? Is it the package maintainer in the |
57 |
> regular tree, or sunrise? |
58 |
|
59 |
> How do you stop excessive bug traffic for issues like this? |
60 |
|
61 |
Assumption is that there will be excessive bug traffic for issues like |
62 |
that. Rules above imo lay it out well enough I don't think it'll |
63 |
occur at the level of "excessive". Basically, sky is falling |
64 |
predictions- no one has hard facts since this is hypothetical, so it |
65 |
would be *nice* if people would at least recognize that they may be |
66 |
barking at a minimal issue. |
67 |
|
68 |
*Plus*, with sunrise under gentoos thumb if it proves to be more |
69 |
trouble then it's worth, the plug can be pulled- that's the trade of |
70 |
it being official, they get hosting, y'all get an actual say in what |
71 |
they do. |
72 |
|
73 |
If they do it externally, ain't much you can do- can't demand they do |
74 |
something (result of that if it were me would be a mooning), stuck |
75 |
requesting them to do what _y'all_ want. |
76 |
|
77 |
|
78 |
> Another issue I think people are ignoring here is the fact that sunrise |
79 |
> isn't focused on a particular part of the tree. I think Ciaran made a |
80 |
> point earlier (that was probably ignored) about the fact of why we have |
81 |
> herds in the regular tree. They aren't perfect, but they still do a |
82 |
> decent job of gathering people who have a good understand about a |
83 |
> certain group of packages. I have a hard time believing that the same |
84 |
> type of quality exists with the number of devs working on it. The |
85 |
> difference between sunrise and say the php overlay is the fact that |
86 |
> sunrise isn't focused on a set of packages (just ones that people want |
87 |
> that aren't in the tree) compared to a focused set for a specific |
88 |
> purpose (php). |
89 |
|
90 |
What is sunrises reason for existance? |
91 |
|
92 |
It's meant to hold ebuilds that _rot_ in bugzilla in a place where |
93 |
people can work on them as needed, and folks who need the packages can |
94 |
use them. They may get bit in the ass since it's a fairly raw repo |
95 |
(despite reviewed branch), but the purpose here is different; it's not |
96 |
intended as a dumping ground (and if it becomes one, council has |
97 |
stated their intentions), it's intended as a repo for people to get at |
98 |
the ebuilds in an easier way, and improve those ebuilds if there is |
99 |
interest. |
100 |
|
101 |
|
102 |
> The more I think about it, I think there needs to be a separation |
103 |
> between "a sandbox for users to hone their ebuild skills" and "these |
104 |
> packages aren't in the tree yet |
105 |
|
106 |
Honing your ebuild skills occurs via practing said ebuild skills. |
107 |
|
108 |
You're not making much of a point here frankly- if ebuild devs won't |
109 |
do a damn thing about an ebuild, who will? That leaves people who are |
110 |
interested in the ebuild. |
111 |
|
112 |
You're basically arguing here that because a dev (who has passed |
113 |
bluntly some arbitary chalk on the wall ebuild test) doesn't have an |
114 |
interest in the package, other folks shouldn't do anything with the |
115 |
ebuild. |
116 |
|
117 |
Phrased that way, it sounds... a bit demanding and out of line. |
118 |
|
119 |
There is a first level, and a second level. What hits the second |
120 |
level is at least reviewed by others (something gentoo-x86 lacks). |
121 |
|
122 |
People _want_ the package, they wouldn't have submitted it to bugzie |
123 |
otherwise- if devs won't do the work, sunrise devs stepping up to help |
124 |
is the best you're going to get. |
125 |
|
126 |
(and prior to anyone screaming "but they may suck", again, note the |
127 |
reviewing- it's a _good_ attempt to deal with that issue). |
128 |
|
129 |
|
130 |
> Whats the real purpose of sunrise then? The sandbox/learning ground? Or a |
131 |
> place for ebuilds that are stuck in bugs? The sunrise project has been |
132 |
> fighting on the grounds of learning aspect, but most of the people are |
133 |
> having issues with the ebuild stomping ground side. If I remember right, |
134 |
> the primary reason the council voted to re-enact sunrise was because of |
135 |
> the learning side of it. I don't doubt that (if done right) would be a |
136 |
> great thing, but I have concerns on the implementation of the latter. |
137 |
|
138 |
Bit daft to assume that sunrise can serve one, and only one purpose. |
139 |
See above, it provides |
140 |
|
141 |
1) area for ebuilds that are bitrotting, thus trying to get a gain out |
142 |
of the original submitters work via sharing it _easily_ with others |
143 |
such that they can use/improve it as needed |
144 |
|
145 |
2) a testing ground for ebuilds prior to actually hitting the tree. |
146 |
Fair bit easier of a sell for a package if it's been exposed to users |
147 |
for 6 months with minimal issue, versus looking at a bug and seeing |
148 |
just an ebuild |
149 |
|
150 |
3) way to enable people who want these things, to contribute. This is |
151 |
both the 'learning ground', and a way to sucker^Wbring more folk into |
152 |
the extended disfunctional family that is gentoo. |
153 |
|
154 |
Further, sunrise is an opt-in setup. People aren't forced to use it, |
155 |
just the same as people aren't forced to use ~arch. If they *do*, |
156 |
they're taking on the costs of using it. |
157 |
|
158 |
|
159 |
> For an example: |
160 |
> |
161 |
> To me, it would work better if the netmon herd brought on a user to help |
162 |
> with the netmon overlay. They would get specific 'training' on working |
163 |
> on netmon ebuilds. They could have done the 'bootcamp' at sunrise |
164 |
> initially, then moved onto the herd overlay for something a bit more |
165 |
> organized and better maintained. This would produce a part of the QA |
166 |
> that some people are in a fuss about, and some better organization. |
167 |
> Heck, maybe even some interaction with the sunrise group and netmon herd |
168 |
> would be great so that the education continues, but on other watchful eyes. |
169 |
> |
170 |
> Basically, it boils down to organization of ebuilds and how they are |
171 |
> being watched. A group that watches all isn't a good idea to me, my idea |
172 |
> above makes more sense. |
173 |
|
174 |
One question then. What if netmon has no interest? |
175 |
|
176 |
What then, because they don't care, for those users who have no |
177 |
option but to work locally, or start their own overlay if they want |
178 |
to share it? |
179 |
|
180 |
Personally, I think herds stepping in and helping would be a good |
181 |
thing. That said, it is _not_ their place to block others from |
182 |
volunteering their efforts (iow, herds doing territorial pissing |
183 |
should not fly). |
184 |
|
185 |
If netmon doesn't want to do anything with sunrise, fine- then it |
186 |
falls to the general maintainers to watch over things. That said, if |
187 |
netmon doesn't want any involvement, that shouldn't block others from |
188 |
trying to contribute (we see enough of that already in mainline |
189 |
gentoo). |
190 |
|
191 |
Now if netmon thinks sunrise is screwing up their packages left and |
192 |
right, well take it to the council/devrel (whichever it falls under)- |
193 |
same way any other project <-> project issue should be dealt with. |
194 |
|
195 |
yes, herd isn't strictly a project, but you get the point- don't like |
196 |
the implicit statement that sunrise is automatically second class |
197 |
citizen to the herd, thus the herd can boss them around. |
198 |
|
199 |
Sunrise *should* defer to the herd when they're not making loco |
200 |
demands, hash out an optimal solution for all parties. Having a |
201 |
defacto "we say it is so" doesn't enable such a setup however. |
202 |
|
203 |
~harring |