1 |
On Wed, Dec 21, 2016 at 07:53:51AM -0500, Rich Freeman wrote: |
2 |
> On Tue, Dec 20, 2016 at 10:49 PM, Daniel Campbell <zlg@g.o> wrote: |
3 |
> > On 12/20/2016 06:33 PM, Rich Freeman wrote: |
4 |
> >> We don't have some |
5 |
> >> committee on high pick a winner and tell all the maintainers that they |
6 |
> >> all have to move from supporting x to supporting y. |
7 |
> > |
8 |
> > Fair points across the board but this stood out to me. We *do* have |
9 |
> > groups that, on some subset of the tree, exert what they feel to be |
10 |
> > winners. QA, the KDE team, and GNOME team have all made formal |
11 |
> > recommendations or requirements that they expect to see in ebuilds going |
12 |
> > forward. QA is blessed by council of course, so they have a bit more |
13 |
> > sway. But we're lying if we say we don't have committees making |
14 |
> > decisions on packaging guidelines. |
15 |
> > |
16 |
> > That's not the same as choosing a single package and telling every one |
17 |
> > to scram, but we're not hands-off, either. |
18 |
> > |
19 |
> |
20 |
> Anybody wishing to add stuff to the main repository does not get a |
21 |
> choice in following QA policy (though these matters can be appealed to |
22 |
> the Council). However, their policies for the most part are fairly |
23 |
> sensible and concern stuff like listing things as a dependency if you |
24 |
> link to them and so on. |
25 |
> |
26 |
> KDE and GNOME developers work as a team, but these teams do not have |
27 |
> any exclusive control over anything in the tree. If a Gentoo |
28 |
> developer doesn't like what they've done with kmail they can add a |
29 |
> kmail2 or kmail-rich0 or whatever that works they way they want it to. |
30 |
> Heck, if a bunch of devs wanted to do their own thing they could start |
31 |
> a kde-improved team if they wanted to. |
32 |
|
33 |
Right, I'm not disagreeing with any of that. I was just pointing out |
34 |
that we *do* have teams that enforce their view of how packages should |
35 |
be handled -- whether with Council's authority (QA) or not (others). |
36 |
Some groups attempt to assert control over certain USE flags, too. Most |
37 |
of the time we just aim for consistency with flags, so I can't fault |
38 |
that. But we're lying to ourselves if we pretend that there aren't |
39 |
groups within Gentoo who exert policy against others and make package |
40 |
decisions, be it legitimate or otherwise. |
41 |
|
42 |
If you want examples, look at gtk <-> gtk2 <-> gtk3, or qt <-> qt4 <-> |
43 |
qt5. Or memcache -> memcached, bikeshedding wrt virtual providers, etc. |
44 |
At a certain point, teams are given the go-ahead by someone in authority |
45 |
(QA or Council usually) to make sweeping changes or urge maintainers to |
46 |
make changes. I'm not saying this is 100% bad; I'm just ensuring we stay |
47 |
honest about what we do as a distro. |
48 |
|
49 |
No value statements are intended. |
50 |
|
51 |
> |
52 |
> In general this doesn't happen, because the developers interested in |
53 |
> maintaining these packages tend to agree on how they want to maintain |
54 |
> them, or at least they don't care enough to bother with forking them. |
55 |
> |
56 |
> How do you think we ended up with eudev? |
57 |
|
58 |
I assume we ended up with eudev because upstream decided that |
59 |
they were going back on their promise that udev would remain usable |
60 |
without systemd. (I can fish up the e-mail -- sent by Lennart himself |
61 |
-- if you'd like. It may take some time) To this day it still is, but |
62 |
that's only until the successor to kdbus wriggles itself into the |
63 |
kernel. At that point, they will have the leverage (and the excuse, in |
64 |
their minds) to drop all support for udev outside of systemd. |
65 |
|
66 |
eudev is an attempt to retain udev as it was originally -- init |
67 |
agnostic. At some point in the future, it will become the only way to |
68 |
get udev outside of systemd. |
69 |
|
70 |
> |
71 |
> -- |
72 |
> Rich |
73 |
> |