From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from lists.gentoo.org ([140.105.134.102] helo=robin.gentoo.org) by nuthatch.gentoo.org with esmtp (Exim 4.50) id 1EddUp-0004G6-7N for garchives@archives.gentoo.org; Sun, 20 Nov 2005 00:55:55 +0000 Received: from robin.gentoo.org (localhost [127.0.0.1]) by robin.gentoo.org (8.13.5/8.13.5) with SMTP id jAK0tCR8024776; Sun, 20 Nov 2005 00:55:12 GMT Received: from smtp.gentoo.org (smtp.gentoo.org [134.68.220.30]) by robin.gentoo.org (8.13.5/8.13.5) with ESMTP id jAK0qor8032725 for ; Sun, 20 Nov 2005 00:52:51 GMT Received: from cpe-65-26-255-237.wi.res.rr.com ([65.26.255.237] helo=nightcrawler) by smtp.gentoo.org with esmtpa (Exim 4.43) id 1EddRq-00013Q-8C for gentoo-dev@lists.gentoo.org; Sun, 20 Nov 2005 00:52:50 +0000 Date: Sat, 19 Nov 2005 18:52:39 -0600 From: Brian Harring To: gentoo-dev@lists.gentoo.org Subject: Re: [gentoo-dev] Email subdomain Message-ID: <20051120005238.GI4535@nightcrawler> References: <1132333748.8524.9.camel@localhost> <200511182022.00662.cshields@gentoo.org> <437EAABE.5050502@gentoo.org> <200511182042.30961.cshields@gentoo.org> <437F93A3.9080808@gentoo.org> <437F9739.4060501@gentoo.org> <20051119221941.GB4535@nightcrawler> <437FAB5B.4060907@gentoo.org> <20051119233804.GF4535@nightcrawler> <437FBDBE.4070801@gentoo.org> Precedence: bulk List-Post: List-Help: List-Unsubscribe: List-Subscribe: List-Id: Gentoo Linux mail X-BeenThere: gentoo-dev@gentoo.org Reply-to: gentoo-dev@lists.gentoo.org Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="J+eNKFoVC4T1DV3f" Content-Disposition: inline In-Reply-To: <437FBDBE.4070801@gentoo.org> User-Agent: Mutt/1.5.11 X-Archives-Salt: c0f4c671-6a19-4374-880c-d74a6705e182 X-Archives-Hash: ec20e7a63267b10eb42e4c469831dec9 --J+eNKFoVC4T1DV3f Content-Type: text/plain; charset=utf8 Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Sat, Nov 19, 2005 at 06:05:18PM -0600, Lance Albertson wrote: > And yes, we probably could/should have said something > about lark earlier, but didn't catch that before hand. Shit happens (lark). The appearance/concerns of cvs (specifically the=20 "this won't fly if it's single key") is what I'm pointing at here. > >>>Sucks, but too damn bad. > >> > >>I'm not going to reply to that. > >=20 > > Probably wise, since it wasn't a friendly jab on my part (for which I= =20 > > should be duly flogged). > > I was rather disappointed in the unprofessional ism of that comment. Eh, I don't have the tolerance you do. :) The phrasing was intended to make it clear that people not tracking=20 what's going on, then getting bit in the ass by it are to some degree=20 at fault. See the apache complaints, and ensuing emerge --news for reasoning=20 behind this one (and yes, the question of how best to push the info=20 out is an issue, but it still requires proactive measures from the=20 people affected). > Solar even mentioned it DURING the meeting to hold on the vote. But > everyone else thought that everything was covered and passing it > wouldn't cause a problem (which was incorrect). Solar got overruled. majority vote... > The hole was closed after they decided on the GLEP. That doesn't make > sense. Why make a rule for it while ignoring the current situation at > hand? This GLEP was the whole reason they added that stipulation, and it > made no sense to me why they didn't apply it to this GLEP they voted > upon. They have the power to do it if it out of common sense. > > Specifically reverting/changing a glep. See glep1 for actual process,= =20 > > or nudge glep41 authors to revise and get council to sign off on it=20 > > (that chunk is somewhat unspecified procedure wise). >=20 > After we sort out details on our end, I might do that. I'll gladly shut up in that case. The concern I have is that the=20 council got stuck in a nasty position, and choose what they thought was an acceptable solution (and modified things so that scenario=20 should never occur again). Reversion based upon next day ml complaints I'm not much for since=20 A) the concern was there, and they made a decision (contraversial=20 or not). B) reverting the decision is doable via existing methods, a call for=20 reversion on the dev ml isn't really one of them (imo). Why am I being a stickler on this? Reversion via ml complaints after=20 the decision opens the door for vocal minorities to try and revert=20 gleps they dislike, rather then having to force their=20 ideas/goals/changes through normal processes (where people can nuke=20 the bad idea/infighting out via normal means) The concern _was_ leveled during the meeting, and decided to move forward. Decision was made. Reverting it (in this case) is a glep thing. Asking the council to reconsider something, well, no procedure=20 (frankly I don't think one is needed either), but it would have to be=20 something that occurs on normal schedule, and would be dependant on=20 the council agreeing to reopen discussion. Considering the nature of=20 this scenario, I *still* posit it's glep territory, through and=20 through. Note that last paragraph is not from any documentation- just a dump of=20 what I think would be wise/best. Everything following really should be chunked off into another thread=20 to iron it out, since it's not glep41 related (although g41 is the=20 catalyst for it). > > re-read it, not implying you are, what I'm stating is that no _group_= =20 > > should have the ability to effectively force the council to=20 > > revert/revote on a decision. Doing so means the council loses the=20 > > ability to have issues passed up to it, and have it agreed upon gentoo= =20 > > wide, and have people actually move forward on something. > >=20 > > Portage shouldn't have it, nor devrel, nor QA, nor infra (obviously my= =20 > > opinion). > >=20 > > And yes, I'm well aware some day a brain dead glep may get forced=20 > > onto the portage group, in which case feel free to taunt me with those= =20 > > words. I'll still stand by my statement from above, despite whatever= =20 > > nasty thoughts may be running through my head. :) > We're all busy, and we're all prone to miss details of happenings that > go on. If infra is going to need to implement something, I would prefer > the folks involved to either email us directly, or come in our channel > talk with with us directly about their proposal. I know I could have > followed the email/glep to get this information, but as you have seen, > we have busy lives outside of Gentoo and can't keep up with everything. > The proper thing for them to do would ask us directly about the proposal > instead of just assuming we watch every single flame email we see on -dev. Personally, I agree within limits. It's not the case currently=20 though (eg, it's not grounds for forcing a reverse of their decision=20 imo). > > Which opens up an interesting question of how to get the council to do= =20 > > a re-vote on something, something that should be a _general_ process=20 > > if implemented, not "we have to implement this, but we think it has=20 > > issues so it should be re-examined". >=20 > We need to have safe guards in place so that infra doesn't get catch > like this again. I have stated many times that I know that the > information was out there for us to see, but we are human and have real > lives. We simply cannot catch everything that goes by. I ask for any > request like this in the future has a direct conversation with infra so > we see the proposal for sure. This is one lack of the council compared to managers; with managers,=20 at least for infra/portage their were members on the board who=20 (usually) knew what was what, and could raise the concerns. It also gave undue power to infra/portage, although that's more of a=20 flaw of the TLP setup. Current council _could_ stand to integrate=20 some form of checkup from groups, but I'd be extremely unhappy if it=20 was any form of actual power, versus just consulting/questioning. Either way, modify the existing setup is fine, just be aware we're=20 bound by it's rules _now_ till it's modified. ~harring --J+eNKFoVC4T1DV3f Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.1 (GNU/Linux) iD8DBQFDf8jWvdBxRoA3VU0RArluAKC+Ao9dPiu7c/jh/8DDVK4jsZFKzgCfUkS2 O/TD0aATqR+x+dVgGxwDJsc= =lnVu -----END PGP SIGNATURE----- --J+eNKFoVC4T1DV3f-- -- gentoo-dev@gentoo.org mailing list