1 |
Am 23.11.2014 um 16:18 schrieb Nicolas Sebrecht: |
2 |
> On Sat, Nov 22, 2014 at 06:20:01PM -0500, Rich Freeman wrote: |
3 |
> |
4 |
>> Don't get me wrong, I'm all for more overlay support. I'm all for |
5 |
>> reform when there is something to reform. However, in all your |
6 |
>> complaints about developers causing conflicts you're actually becoming |
7 |
>> part of the problem. |
8 |
> I'd say the problem is not about the devs themselves causing conflicts |
9 |
> but the environment and frame devs are working in the current workflow. |
10 |
> Everybody look baffled with the current way of doing things in Gentoo. |
11 |
> |
12 |
> I agree with hasukel that the "distributed Gentoo" as proposed today is |
13 |
> a wrong answer. Not that the issues raised are not valid. They do. |
14 |
> |
15 |
> Also, I agree with hasukel that the main problem is about having a |
16 |
> correct distributed model. Posting on bugzilla for ebuilds updates or |
17 |
> new ebuilds is seriously damaging when almost every where else it is |
18 |
> just about sending your git patches. Becoming an official Gentoo dev is |
19 |
> not a solution either due to the recruiting process. |
20 |
> |
21 |
> As you say, official devs can work on whatever they like and their |
22 |
> contributions will likely hit the users at some point while at the same |
23 |
> time occasional devs are asked to work with old tools like bugzilla. So |
24 |
> yes, the whole review process is broken and the contribution process is |
25 |
> broken too. |
26 |
> |
27 |
> About that, there's no other way than break the whole recruiting process |
28 |
> and change of tools. Have your core team handle git repositories and let |
29 |
> others request pull or send patches like almost all the other open |
30 |
> source softwares in the world. Let's exploit the anarchy and openness |
31 |
> instead of partitionning things into devs/non-devs or main-tree/overlays. |
32 |
> |
33 |
> |
34 |
> Back to the original request. Here is how starts the "distributed |
35 |
> Gentoo" model: |
36 |
> |
37 |
> Imagine you would say "I like gentoo, but I don't like the way the |
38 |
> toolchain is handled, so I want to do it differently". Currently, your |
39 |
> only way is to fork the whole distro or do dangerous stuff with |
40 |
> overlays. |
41 |
> |
42 |
> Imagine gentoo would actually be a small repository of core packages |
43 |
> with lots of optional user contributed extenions of all kinds. You'd |
44 |
> only need to fork the core and add those extensions you like. |
45 |
> |
46 |
> Similarly... you don't like the way ruby is handled? Well, apart from |
47 |
> dev-lang/ruby maybe, there'd be no ruby gems in the tree anyway. So |
48 |
> there can be different approaches of packaging ruby gems and you choose |
49 |
> which to use or if you want to do it completely different. And there |
50 |
> would be no complicated configuration required to prevent in-tree ruby |
51 |
> packages getting pulled in, because there are none. |
52 |
> |
53 |
> Isn't this all stuff about handling some kind of pointers? Don't like |
54 |
> the toolchain? Point to another one. Don't like the way ruby is handled? |
55 |
> Point to another one. |
56 |
> |
57 |
> So, is it about overlays? No. I'd say overlays are some kind of poor |
58 |
> pointers for many reasons. |
59 |
> |
60 |
> Hence, why not adding the pointers we are all missing and rethinking the |
61 |
> other pointers? |
62 |
> |
63 |
|
64 |
am I the only one who thinks that this way leads to madness? |
65 |
|
66 |
Version conflicts are bad enough. No multiply that with a bunch of |
67 |
overlays, all having their own libXY with just some tiny, tiny |
68 |
differences, and another bunch of overlays who want libXY from certain |
69 |
others.... |
70 |
|
71 |
if that does not give you nightmares, I don't know what. |