1 |
On 06/15/2016 12:22 AM, Alexander Berntsen wrote: |
2 |
> On 14/06/16 08:48, Daniel Campbell wrote: |
3 |
>> What sort of modularization are you talking about? |
4 |
> The cheap answer is "as much as possible. |
5 |
> |
6 |
>> Would we suggest something like GNOME, KDE, XFCE, Mate, Cinnamon, |
7 |
>> et al getting their own overlays? dev-lang/foo getting its own |
8 |
>> overlay, etc? |
9 |
> Yes. Although I would not want to impose my thoughts too much in this |
10 |
> regard, as I think we have a lot of capable devs, who are hopefully more |
11 |
> fit for this task than I am. |
12 |
> |
13 |
>> To some degree, that will simplify some people's trees and quicken |
14 |
>> emerge, but then it just pushes maintainance to a part that most |
15 |
>> users don't really mess with much (repos.conf) |
16 |
> I don't know what maintenance you are speaking about. |
17 |
|
18 |
There is overhead in choosing which repositories you want to include in |
19 |
your 'upstream'. Even with an automated tool like layman, there's |
20 |
maintenance overhead. We'd need another tool to assist in |
21 |
discoverability, too. Let's say this idea takes off and we start with |
22 |
100-200 user repos. It's meaningless to learn that there are that many |
23 |
repositories and list them (that's what layman currently does). What's |
24 |
important is getting a list of *which packages* those repos have, even |
25 |
if it's one-by-one and cat'd to a file. |
26 |
|
27 |
Even if that is written, it adds yet another facet to system administration. |
28 |
> |
29 |
>> You can achieve mostly the same end via your own git repo at |
30 |
>> /usr/local/ and pulling overlays in via either layman or git |
31 |
>> submodules, for overlays that aren't already in layman. |
32 |
> The repository isn't hosted by us along with everybody else's |
33 |
> repository, so there is no community element. And the Gentoo tree isn't |
34 |
> modular today. So I completely fail to see how that would be "mostly the |
35 |
> same". |
36 |
> |
37 |
>> zugaina and layman are great tools that could use a bit more |
38 |
>> polish, and could be either adopted or assisted as an official part |
39 |
>> of the handbook. |
40 |
> That would be great. |
41 |
> |
42 |
>> There's no guarantee on their quality, and if an overlay becomes |
43 |
>> popular then there may be pressure put on the Gentoo tree to adopt |
44 |
>> whatever the popular overlay has. This could be detrimental *or* |
45 |
>> beneficial, depending on what the changes are. |
46 |
> I assume that using PPAs is at your own risk, so this is not a real |
47 |
> problem. Gentoo would have a curated and reviewed set of repositories, |
48 |
> venturing outside of that is clearly for power users. |
49 |
> |
50 |
Okay, and who chooses which ones get curated? Developers? The whole goal |
51 |
of this decentralization, from what I gather, is community. If |
52 |
developers are overseeing it all, it adds overhead to developers and |
53 |
doesn't really foster community control or support. |
54 |
|
55 |
If the goal is community then it should be *community curated*, which |
56 |
means it can exist entirely outside of Gentoo's infra and we shouldn't |
57 |
have to care about it. Why do Gentoo devs need to curate it if the aim |
58 |
is community control? In fact, that's already possible right here, right |
59 |
now. |
60 |
|
61 |
I'm not against the idea per se, but at the same time I don't see why |
62 |
it's the responsibility of developers to make this sort of thing happen. |
63 |
It's not a trivial thing we can mark off in a checklist. However, there |
64 |
are enough tools in the Gentoo toolbox to make such a thing happen -- if |
65 |
the community wants it. And if they want it, they can build it. We don't |
66 |
do anything, to my knowledge, to stifle the growth of community |
67 |
repositories. |
68 |
-- |
69 |
Daniel Campbell - Gentoo Developer |
70 |
OpenPGP Key: 0x1EA055D6 @ hkp://keys.gnupg.net |
71 |
fpr: AE03 9064 AE00 053C 270C 1DE4 6F7A 9091 1EA0 55D6 |