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