From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from lists.gentoo.org (pigeon.gentoo.org [208.92.234.80]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by finch.gentoo.org (Postfix) with ESMTPS id 4110B139085 for ; Thu, 22 Dec 2016 01:19:57 +0000 (UTC) Received: from pigeon.gentoo.org (localhost [127.0.0.1]) by pigeon.gentoo.org (Postfix) with SMTP id EB33E2241D7; Thu, 22 Dec 2016 01:19:43 +0000 (UTC) Received: from smtp.gentoo.org (smtp.gentoo.org [140.211.166.183]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by pigeon.gentoo.org (Postfix) with ESMTPS id 804FB21C012 for ; Thu, 22 Dec 2016 01:19:43 +0000 (UTC) Received: from sporkbox (anon-34-8.vpn.ipredator.se [46.246.34.8]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) (Authenticated sender: zlg) by smtp.gentoo.org (Postfix) with ESMTPSA id 9ECA4341026 for ; Thu, 22 Dec 2016 01:19:41 +0000 (UTC) Date: Wed, 21 Dec 2016 17:19:35 -0800 From: Daniel Campbell To: gentoo-user@lists.gentoo.org Subject: Re: [gentoo-user] from Firefox52: NO pure ALSA?, WAS: Firefox 49.0 & Youtube... Audio: No Message-ID: <20161222011934.GD10145@sporkbox> References: <1539590.2abgqJ6fBz@thetick> <20161220225155.GA6010@acm.fritz.box> <8ceb1f71-e8c3-d7ec-9d0e-6025baa0a296@gentoo.org> Precedence: bulk List-Post: List-Help: List-Unsubscribe: List-Subscribe: List-Id: Gentoo Linux mail X-BeenThere: gentoo-user@lists.gentoo.org Reply-to: gentoo-user@lists.gentoo.org MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="ieNMXl1Fr3cevapt" Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.7.2 (2016-11-26) X-Archives-Salt: d331616a-04fe-4359-ba1d-d68cdf4ada78 X-Archives-Hash: 6c7ccc41bb412d740bc100766ea7e2ef --ieNMXl1Fr3cevapt Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Wed, Dec 21, 2016 at 07:53:51AM -0500, Rich Freeman wrote: > On Tue, Dec 20, 2016 at 10:49 PM, Daniel Campbell 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. > > >=20 > 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. >=20 > 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. >=20 > 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. >=20 > 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. >=20 > --=20 > Rich >=20 --ieNMXl1Fr3cevapt Content-Type: application/pgp-signature; name="signature.asc" Content-Description: Digital signature -----BEGIN PGP SIGNATURE----- iQIzBAEBCAAdFiEEgIn+0tMDW9PQWDLnASQOlFA54XAFAlhbKiYACgkQASQOlFA5 4XBLnA//Sxf/DJorSNcqeCTpzCfZY5BrimDRoUarHa5Owlbp7kBOVm1FFSdoyjCr qM+UsPvpmtAQE4rL5NrYjX7Cfv/q+huw42AbwkQQhMcIzmYYNzwNujvZiUukXUcV Jtv+BY5H1nBC7OlnX/M2eQQx4Fj+dUasyvVS5YNfIppydw7LzZDgT6NR+lwqDnE/ ZHMGezh0rWBt8oD6CmgEe3xhcmK02i1uKYtLZ40ND9Cje8boyU7Xskey52k3MLlo TmCgxgpq57y1h11ZhzREmH0JjI+5jf858sKbZn9JRJ5UHXVH7tmsoFM8sNEG0pbP ovkadSnHGyQjTJA4LhfKCIzdN4v2OqF+6CC/pjxrJbEMG9YD0PiZ0gWuOZfA3Edv Pg9HBjHLNC7grbgu8OuOlhXUEk8vyzCu5g31eJ0ApNzHd5ok0WrB30zOJ3qUiYwB 2YaLHOB/9KQoSnayh4pvriE6wGn2so4NfDWxKqo35qoJMPBM+a6vAKtC02WVAx2J dKGhai+LW9fAtfBqkTYppxW2Bq68AZKbTnsTPhAXLpQ9/0yBGbe0uA49gRwlZxi0 etAN5VoSLLREfUwMhSR9NM5tLTRnxCta16vuoSbS6YBWInZVHHKQanf+hFly9Spl vhLyLWSrasHhN4JfCBHdNgk3HY9XERiRxx2VuAsfRG5G3akzlRg= =cIF0 -----END PGP SIGNATURE----- --ieNMXl1Fr3cevapt--