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 1EdcL4-000718-Qh for garchives@archives.gentoo.org; Sat, 19 Nov 2005 23:41:47 +0000 Received: from robin.gentoo.org (localhost [127.0.0.1]) by robin.gentoo.org (8.13.5/8.13.5) with SMTP id jAJNeP1u000575; Sat, 19 Nov 2005 23:40:25 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 jAJNcFm3006253 for ; Sat, 19 Nov 2005 23:38:15 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 1EdcHf-0003sQ-2R for gentoo-dev@lists.gentoo.org; Sat, 19 Nov 2005 23:38:15 +0000 Date: Sat, 19 Nov 2005 17:38:04 -0600 From: Brian Harring To: gentoo-dev@lists.gentoo.org Subject: Re: [gentoo-dev] Email subdomain Message-ID: <20051119233804.GF4535@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> 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="9ADF8FXzFeE7X4jE" Content-Disposition: inline In-Reply-To: <437FAB5B.4060907@gentoo.org> User-Agent: Mutt/1.5.11 X-Archives-Salt: 88af27a5-d672-42bf-83f0-e820e3dcd05c X-Archives-Hash: 3e152d9d6ba6224c987038e952fc8227 --9ADF8FXzFeE7X4jE Content-Type: text/plain; charset=utf8 Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Sat, Nov 19, 2005 at 04:46:51PM -0600, Lance Albertson wrote: > Brian Harring wrote: > > It's a crazy notion, but y'all could've commented in the *TWO* months= =20 > > that this glep has been percolating, "yo, what do you want from an=20 > > infra standpoint?". > >=20 > > Or implemented anoncvs in the meantime, thus nuking the main request=20 > > that's being made of infra. >=20 > What was posted two months ago is not the same as was posted a day > before the vote. I didn't see a problem with the original glep from an > infra POV, thus why I didn't say much about it. Email wise, you're right- the basic issue of anoncvs/cvs ro access for=20 ATs however has been in the glep from the beginning (regardless of the=20 glep having a minimal req tacked into it). That said, the subdomain bit has been available since the oct council=20 meeting. Not something that was particularly sprung, although grounds=20 for arguing that it wasn't pushed out in the best manner. That still doesn't address my point about the basic need of the glep,=20 anoncvs/cvs ro being known. > > It is your guys responsibility to keep up to date on what's underway. > > Portage devs do it, arches do it, infra is no different. > >=20 > > That's why you're on this ml- that is why gleps get sent to this ml- so= =20 > > that all of the various groups can weigh in. >=20 > The revised GLEP in question was posted a day before the vote. I was > watching it, though I didn't get a chance to read through the whole GLEP > for the changes at the time since I was busy with real life issues. This > is why I stated in an email [1] that day that they should postpone > voting on it. > [1] http://marc.theaimsgroup.com/?l=3Dgentoo-dev&m=3D113199543120777&w=3D2 Reading through it, it reads more like a comment about the process. =20 It's also not an explicit request that it be delayed, which I'll=20 assume is just me misreading it. > > You guys want the glep changed, either ask hparker and crew nicely, or= =20 > > submit your own glep. You've had time to be involved, and you've=20 > > admitted you saw but did not even comment "we need to review this,=20 > > it must be delayed". >=20 > Considering how the revised GLEP went through without ANY discussion > prior to the vote, I don't see why we need to. That is an issue of the > procedure used to to get this GLEP approved which wasn't done correctly. > I have yet to see a valid reason for pushing ahead for the vote (and > yes, I read the log.. see my comments in previous emails about that > logic they used). Said hole has been closed; what I'm stating is that y'all should work=20 through what's available rather then a forced re-vote. See tail end=20 of email for reasoning. > > I see this mainly as infra/trustees not watching the ML. >=20 > What does trustees have to do with this GLEP? And yes, I was watching > the ML, but giving me 24hr to respond to a GLEP revision before a vote > is not reasonable. Knowing what the revisions where going to be (previous meeting) makes=20 the 24 hour comment a bit off. > > Frankly it seems like y'all didn't pay attention, and got caught with= =20 > > your pants down. >=20 > Thats not the case, we got a revised GLEP one day before the vote and > didn't have a chance to reply reasonably. Email is about the only snafu out of this whole thing that is=20 reasonably questionable imo. Concerns about load on lark, handling=20 the new users, etc, no, as I stated, this glep has been around for 2=20 months without infra asking what's required. That's the crux of the "caught with the pants down". The fact that=20 the initial glep could've passed, and still there would be=20 complaints/issues brought up (beyond email concerns) afterwards=20 because people didn't pay attention. > > Sucks, but too damn bad. >=20 > I'm not going to reply to that. Probably wise, since it wasn't a friendly jab on my part (for which I=20 should be duly flogged). > > And no... bitching about the window for the revision isn't really=20 > > valid, since the requested revisions to the glep from the council have= =20 > > been known for a month already (again, more then reasonable time to=20 > > know what is afoot). >=20 > Where was it stated that it was posted and was being discussed? Just > because it was stated in a meeting log and was committed in cvs doesn't > mean I need to read cvs changelogs. I expect the information about the > GLEP i need to know about to be in the GLEP and that the revised GLEP to > be sent with ample time before the meeting at hand. This was not done > and this is why I'm frustrated with the situation. Again.. aside from email, the info's been out there. > We have yet to figure out how we're going to do this. >=20 > > Email subdomain? Go through the channels everyone else has to. >=20 > Huh? 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). > > Reversion is not an option from where I'm sitting, regardless of the=20 > > power infra wields over gentoo or how much y'all may dislike the glep.= =20 > > Change it via the methods available, rather then the kicking/screaming. >=20 > I'm not abusing our power, 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. Portage shouldn't have it, nor devrel, nor QA, nor infra (obviously my=20 opinion). 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. :) > I'm simply pointing out the fallacy of the > events that transpired. I feel that we should not have to implement > something that was posted a day before the vote. I *was* watching the > mailing lists and I *do* try and catch these things, and I *tried* to > have them postpone the vote. But as you can tell, something was > obviously out of sync communication wise because I didn't see this coming. *again*, beyond email concerns, the issues y'all are bringing up=20 weren't sprung on you. anoncvs/cvs ro access has been known for quite=20 some time. Restating the point, the changes were known for a freaking month prior=20 to the vote. It's not out of the blue, nor is the cvs ro requirement. > All I'm after is this vote to be properly reconsidered because of a=20 > mandate they accepted after they accepted this GLEP. 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". ~harring --9ADF8FXzFeE7X4jE Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.1 (GNU/Linux) iD8DBQFDf7dcvdBxRoA3VU0RAlzWAJ4oYZ4GcntEvS+aq3ly8ePCNys83QCfaVf4 s3IvnwMM+AnrTlM7aA7bSpg= =zZpZ -----END PGP SIGNATURE----- --9ADF8FXzFeE7X4jE-- -- gentoo-dev@gentoo.org mailing list