1 |
Jesús Guerrero wrote: |
2 |
> Yeah, devs for that as well. |
3 |
> |
4 |
|
5 |
Yup - I think we're actually on the same page. Ultimately quality |
6 |
matters more than quantity and everybody does what they can given the |
7 |
resources we have. |
8 |
|
9 |
>> Right now it is at least a little painful to get set up with an overlay. |
10 |
> No, it's a matter of using layman -a <whatever> |
11 |
|
12 |
Sure, and that is fine if overlays are intended only as experimental |
13 |
development spaces. However, some (not necessarily including yourself) |
14 |
advocate that it is perfectly fine that the portage tree gets stale |
15 |
since we have all those overlays. That certainly is a possible approach |
16 |
to take, but to go that route overlays need to become more robust. |
17 |
Right now they're really not a replacement for /usr/portage. |
18 |
|
19 |
> There's no policy. Just like unofficial repos for any other distro. |
20 |
> We can't control that. It's outside Gentoo. |
21 |
|
22 |
Exactly. And, because it is outside of Gentoo - packages in overlays |
23 |
don't count when we consider how up-to-date Gentoo is. If we want to |
24 |
say that package foo isn't stale because there are recent versions in |
25 |
some overlay, then Gentoo needs to take responsibility for the overlays. |
26 |
That might be as simple as being a gatekeeper - auditing overlays and |
27 |
booting ones that drift out of control. |
28 |
|
29 |
> I don't think we can do any more with the number of developers we |
30 |
> have right now unless we start dumping blindingly and without any check |
31 |
> every ebuild that we get across. |
32 |
> |
33 |
|
34 |
Absolutely. The whole logic behind going to an overlay-based approach |
35 |
is that it allows developers to leverage external help more effectively |
36 |
- a developer can essentially delegate a whole mini portage-tree to some |
37 |
other entity to manage, simply providing oversight and QA. In theory |
38 |
you could even have official overlays - which would allow better |
39 |
delineation of responsibilities (you don't need to grant people commit |
40 |
access to everything - just their project's overlay). |
41 |
|
42 |
Ultimately, as you argue, it doesn't make a difference if nobody is |
43 |
willing to step up and actually maintain ebuilds. |
44 |
|
45 |
Personally, I like the overlay idea, but right now it just isn't |
46 |
necessary. In theory proxy maintainers work almost as well, and we're |
47 |
not really making heavy use of this model right now. If we had hundreds |
48 |
of users submitting high-quality ebuilds in bugzilla and simply couldn't |
49 |
find enough devs to commit them all, then a more overlay-based approach |
50 |
would help reduce the bottleneck of having a centralized group of |
51 |
committers. Right now we probably have far more devs than proxy-devs, |
52 |
so the need to delegate the tree further really isn't there. |