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 E5046138334 for ; Thu, 28 Jun 2018 20:08:27 +0000 (UTC) Received: from pigeon.gentoo.org (localhost [127.0.0.1]) by pigeon.gentoo.org (Postfix) with SMTP id E1BFBE08F5; Thu, 28 Jun 2018 20:08:26 +0000 (UTC) Received: from smtp.gentoo.org (dev.gentoo.org [IPv6:2001:470:ea4a:1:5054:ff:fec7:86e4]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by pigeon.gentoo.org (Postfix) with ESMTPS id 8BA92E0876 for ; Thu, 28 Jun 2018 20:08:26 +0000 (UTC) Received: from monkey.localnet (pool-71-163-21-11.washdc.fios.verizon.net [71.163.21.11]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) (Authenticated sender: bman) by smtp.gentoo.org (Postfix) with ESMTPSA id 6B3C3335C96 for ; Thu, 28 Jun 2018 20:08:25 +0000 (UTC) From: Aaron Bauman To: gentoo-project@lists.gentoo.org Subject: Re: [gentoo-project] [RFC] pre-GLEP: Gentoo General Resolution Date: Thu, 28 Jun 2018 16:08:22 -0400 Message-ID: <3726370.3QyFztr4L0@monkey> In-Reply-To: References: <1530202455.901.3.camel@gentoo.org> <2161410.MAeoZWknrX@monkey> Precedence: bulk List-Post: List-Help: List-Unsubscribe: List-Subscribe: List-Id: Gentoo Project discussion list X-BeenThere: gentoo-project@lists.gentoo.org Reply-To: gentoo-project@lists.gentoo.org MIME-Version: 1.0 Content-Type: multipart/signed; boundary="nextPart2837931.kOjNGN4fh5"; micalg="pgp-sha256"; protocol="application/pgp-signature" X-Archives-Salt: 9c72a07b-99cf-46e9-abf5-08281977bbad X-Archives-Hash: e5acfffdf2984f29b38eac75d5dea004 --nextPart2837931.kOjNGN4fh5 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="UTF-8" On Thursday, June 28, 2018 3:33:24 PM EDT Rich Freeman wrote: > On Thu, Jun 28, 2018 at 3:03 PM Aaron Bauman wrote: > > On Thursday, June 28, 2018 1:24:27 PM EDT Rich Freeman wrote: > > > On Thu, Jun 28, 2018 at 12:14 PM Micha=C5=82 G=C3=B3rny wrote: > > > > a. the Council decision in question is final (i.e. a general > > > > =20 > > > > resolution can not be used to bypass the Council), > > >=20 > > > One question that this brings up in my mind is the duration of these > > > decisions, because Council decisions are never really final. The > > > Council can override its own decisions, or the decision of a prior > > > Council. > >=20 > > By this logic then nothing is final. We might as well throw it all awa= y. >=20 > Finality has nothing to do with throwing stuff away. Decisions are > made at a point in time. They aren't generally discarded lightly, but > they also aren't clung to when they no longer make sense. That is all > I'm getting at. >=20 > > It is my impression that the GR is not "overridable" because it is a > > developer wide vote. The important people are the developers... >=20 > Great. Then write that into the GLEP so that is clear. My whole > point is that we shouldn't have to rely on your "impression." >=20 It is clear. It is understood. If you have an issue with it then send mgo= rny=20 a patch. As stated, it nullifies a particular decision. Plain and simple. > > A council vote should *absolutely* be required to change the default > > service manager. >=20 > Sounds like you'll be needing another GLEP then. What other decisions > should explicitly require Council votes? >=20 "Global issues". Again, we can't legislate common sense. > GLEP 39 only requires them when there are disagreements between > projects. In the absence of disagreement between projects, no Council > votes are required. >=20 Looks like you need to read GLEP39 again. The word agreement isn't even fo= und=20 in it. (Hint: "Global issues will be decided by an elected Gentoo council.") > > The GR GLEP, as Micha=C5=82 has written it, does indeed not have an exp= iration > > date. The assumption you have made here worries me though. We *cannot* > > legislate common sense. By the developer community enacting the general > > resolution it is nullifying that particular decision. The controls of > > which are clearly outlined. >=20 > I'm not sure what "assumption" I've made here. I've simply pointed > out that nothing in the policy states how a GR is to be reversed. I > then proposed scenarios for how that could cause questions to come up. > My goal is to make the policy less ambiguous. >=20 It doesn't *need* to be reversed. It is a nullification of a decision beca= use=20 of disagreement by the developer community. So, the council should react b= y=20 trying something that is "in line" with the issues that were brought up. =20 Plain and simple. > > A subsequent council would simply propose another vote to change the > > default service manager when the time is appropriate. It should be cle= ar > > as to why the GR was enacted (which is detailed in the GLEP) and it > > should be clear to any subsequent voting members what issues the > > *developers* had with it. > If there is no longer any controversy over the new decision (which > might be many years later), why require an all-dev vote? And of > course a GR can always be used to re-override the Council decision if > necessary. Obviously you'd want some controls on this so that we > don't end up with the same issues being re-voted upon repeatedly. >=20 No, the council just proposes a new/modified proposal to vote on. This sho= uld=20 have been a product of civil discourse. Understanding what the issues were= =20 and addressing them. e.g. "The developer community believes service manager X goes against Gento= o=20 principals." Council: "Ok, here is a modified proposal addressing this concern" > > > To use a different example, consider GLEP 39. Many consider GLEP 39 > > > to be special and one that the Council cannot modify, but on the flip > > > side there is currently no real defined process for changing it. > > > (Perhaps GRs will become such a mechanism.) The result is that > > > sometimes changes that might make sense don't really get considered > > > because nobody feels empowered to make it happen. > >=20 > > I don't see why the developer community cannot change GLEP 39 if they so > > chose too. Just no one has wanted to do it. >=20 > Probably because it is a hassle with no defined process. I'm pointing > out that a GR could turn into a similar hassle. Ok, a decision no > longer makes sense, but it is so painful to change that we just live > with it. After all, a new GR requires collecting a bunch of GPG > signatures/etc, even if all the devs and the Council agree with it. > Or should the GR GLEP include a way for the Council to kick off a GR > without the need for the requisite number of individual votes? Maybe > offer that as another option - the Council can initiate a GR with a > majority vote? >=20 What? The council can initiate GR to overrule itself? > Again, my goal here is to improve the GLEP. It isn't some kind of > objection to the concept. >=20 > > > In any case, my point is mainly that the GR GLEP ought to indicate one > > > way or another how a GR can be modified. Presumably a GR can always > > > be used to modify a previous GR. However, do we want to relax things > > > further, such as by allowing GRs to be overriden by Council if there > > > has been a Council election in the interim? > >=20 > > No. The point of the GR is to override council. Not the opposite. So, > > please see the previous paragraphs I wrote above. It nullifies a > > particular decision. The new council will simply try to pass something > > new or modified to fit the needs of the community. >=20 > Presumably they can't pass something new or modified if it is related > to an existing GR, because that would be overriding a GR, which you > don't think ought to be allowed, even if it does better fit the needs > of the community. >=20 You didn't read what I wrote. > If the Council wanted to pass something new or modified they'd need to > propose it as a new GR. As such, the GRs really should be able to > stand on their own without tweaking, because they're going to be hard > to tweak. >=20 > > Please *stop* using the volunteer thing as a crutch. >=20 > Not sure where I ever suggested that being a volunteer excused > non-compliance with policy. I simply pointed out that volunteers may > not be enthusiastic about doing things they disagree with. That is > just reality. It certainly shapes Council decisions, as it ought to. > And again it was more of a philosophical point than a defect that > needed to be addressed. You do often. --nextPart2837931.kOjNGN4fh5 Content-Type: application/pgp-signature; name="signature.asc" Content-Description: This is a digitally signed message part. Content-Transfer-Encoding: 7Bit -----BEGIN PGP SIGNATURE----- iQEzBAABCAAdFiEEiDRK3jyVBE/RkymqpRQw84X1dt0FAls1QDYACgkQpRQw84X1 dt1pkwf+NRSEhJVlSNulGX5U/cnUJ/ze+e0VMtTb7arc8N7WCEiWI/kcbhYkccmZ 9Bl8ZGz86JDUh8aRk38EBcNEx0eMLDAWgIqwADQAqVgqTgSnIM21hGvoZJA2eMx/ JigcKTOFNpzHWab1z0uORPrCkPGNJ/NTFVbGLYqolfdQShwFUjmpErBPIE2fZIr7 NVf7rROoDRB84G3GrxiV8zyUQ+Ez5ShqAvOzX+KQWmBiSWFFVucwWBQqrlmsvFK2 GX4CR14A34e5Y0FxXIDI6Wbj6s1hwYhT3HS4bcUm+GGrNL5XCK/yZ2dNxgETjapB K4UIdkwj4H09dngw3wVrPiEzDqoJwg== =5MoY -----END PGP SIGNATURE----- --nextPart2837931.kOjNGN4fh5--