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 1Edbab-0003H3-Du for garchives@archives.gentoo.org; Sat, 19 Nov 2005 22:53:46 +0000 Received: from robin.gentoo.org (localhost [127.0.0.1]) by robin.gentoo.org (8.13.5/8.13.5) with SMTP id jAJMqJQv007634; Sat, 19 Nov 2005 22:52:19 GMT Received: from centrmmtao04.cox.net (centrmmtao04.cox.net [70.168.83.80]) by robin.gentoo.org (8.13.5/8.13.5) with ESMTP id jAJMkqa4023578 for ; Sat, 19 Nov 2005 22:46:53 GMT Received: from [10.3.1.3] (really [68.102.201.166]) by centrmmtao04.cox.net (InterMail vM.6.01.05.02 201-2131-123-102-20050715) with ESMTP id <20051119224536.TILP8318.centrmmtao04.cox.net@[10.3.1.3]> for ; Sat, 19 Nov 2005 17:45:36 -0500 Message-ID: <437FAB5B.4060907@gentoo.org> Date: Sat, 19 Nov 2005 16:46:51 -0600 From: Lance Albertson User-Agent: Mozilla Thunderbird 1.0.7 (X11/20051026) X-Accept-Language: en-us, en 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 To: gentoo-dev@lists.gentoo.org Subject: Re: [gentoo-dev] Email subdomain 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> In-Reply-To: <20051119221941.GB4535@nightcrawler> X-Enigmail-Version: 0.92.0.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="------------enig02C980C317F3397AD4E2B045" X-Archives-Salt: 50c385bc-9025-486c-81cb-dfd0e936929d X-Archives-Hash: 82e9d9ea77886d495fa2fb1f62d55eee This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --------------enig02C980C317F3397AD4E2B045 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Brian Harring wrote: > Frankly I think you're exagerating here. > > You're seriously telling me it's going to cause you massive > adminstration nightmares adding an attribute to ldap to specify the > user comes in from a subdomain? Where's the nightmare in admining it? > It _should_ just be a setup cost. > > If that's not the case, I question your setup. There's far more things to worry about aside from ldap and email. I'm hoping to list them out soon, but I have other things I'm doing this weekend. > It's a crazy notion, but y'all could've commented in the *TWO* months > that this glep has been percolating, "yo, what do you want from an > infra standpoint?". > > Or implemented anoncvs in the meantime, thus nuking the main request > that's being made of infra. 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. > 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. > > That's why you're on this ml- that is why gleps get sent to this ml- so > that all of the various groups can weigh in. 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=gentoo-dev&m=113199543120777&w=2 > So... infra can bitch, and have the council vote reversed? > > What about portage group, do we have the same power? QA? Devrel? > > Y'all haven't offered any input into this glep in the 2 months it's > been around. Further, *you* did see the glep, and didn't get off > your ass and state "hey guys, this has to be delayed- infra needs to > review it". See above [1]. I asked for them to hold on the vote and that did not happen. > You guys want the glep changed, either ask hparker and crew nicely, or > submit your own glep. You've had time to be involved, and you've > admitted you saw but did not even comment "we need to review this, > it must be delayed". 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). > I see this mainly as infra/trustees not watching the ML. 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. > Frankly it seems like y'all didn't pay attention, and got caught with > your pants down. Thats not the case, we got a revised GLEP one day before the vote and didn't have a chance to reply reasonably. > Sucks, but too damn bad. I'm not going to reply to that. > And no... bitching about the window for the revision isn't really > valid, since the requested revisions to the glep from the council have > been known for a month already (again, more then reasonable time to > know what is afoot). 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. > As I already pointed out, the cvs issue klieber is beating over > everyone's head is missing the fact it's a suggested route- go > the standard ldap user route, and the issues disappear. We have yet to figure out how we're going to do this. > Email subdomain? Go through the channels everyone else has to. Huh? > Reversion is not an option from where I'm sitting, regardless of the > power infra wields over gentoo or how much y'all may dislike the glep. > Change it via the methods available, rather then the kicking/screaming. I'm not abusing our power, 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. > I'm going to keep my mouth shut on the backdoor comment, aside from > stating that's behaviour I hope to _never_ see out of a trustee again. > ~harring *sigh* You're taking what I'm saying way too personally. All I'm after is this vote to be properly reconsidered because of a mandate they accepted after they accepted this GLEP. I've already tried to figure out all the logistics of what they accepted, so I'm not doing the whole "i'm stomping my foot down on this and not doing it". -- Lance Albertson Gentoo Infrastructure | Operations Manager --- GPG Public Key: Key fingerprint: 0423 92F3 544A 1282 5AB1 4D07 416F A15D 27F4 B742 ramereth/irc.freenode.net --------------enig02C980C317F3397AD4E2B045 Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.1 (GNU/Linux) iD8DBQFDf6tbQW+hXSf0t0IRAuqWAJ4tiFFK9vIDCcoCFV/y9MPeQkH2cwCgvRm9 R61kFAE3pqFOX+d7uSFF0Bc= =NluR -----END PGP SIGNATURE----- --------------enig02C980C317F3397AD4E2B045-- -- gentoo-dev@gentoo.org mailing list