Re: [gentoo-dev] Email subdomain

[Brian Harring <ferringb@gentoo.org>]

[-- Attachment #1: Type: text/plain, Size: 7097 bytes --]

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 
> > 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.

Email wise, you're right- the basic issue of anoncvs/cvs ro access for 
ATs however has been in the glep from the beginning (regardless of the 
glep having a minimal req tacked into it).

That said, the subdomain bit has been available since the oct council 
meeting.  Not something that was particularly sprung, although grounds 
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, 
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.
> > 
> > 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

Reading through it, it reads more like a comment about the process.  
It's also not an explicit request that it be delayed, which I'll 
assume is just me misreading it.

> > 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).

Said hole has been closed; what I'm stating is that y'all should work 
through what's available rather then a forced re-vote.  See tail end 
of email for reasoning.

> > 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.

Knowing what the revisions where going to be (previous meeting) makes 
the 24 hour comment a bit off.

> > 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.

Email is about the only snafu out of this whole thing that is 
reasonably questionable imo.  Concerns about load on lark, handling 
the new users, etc, no, as I stated, this glep has been around for 2 
months without infra asking what's required.

That's the crux of the "caught with the pants down".  The fact that 
the initial glep could've passed, and still there would be 
complaints/issues brought up (beyond email concerns) afterwards 
because people didn't pay attention.

> > Sucks, but too damn bad.
> 
> I'm not going to reply to that.

Probably wise, since it wasn't a friendly jab on my part (for which I 
should be duly flogged).

> > 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.

Again.. aside from email, the info's been out there.


> We have yet to figure out how we're going to do this.
> 
> > Email subdomain?  Go through the channels everyone else has to.
> 
> Huh?

Specifically reverting/changing a glep.  See glep1 for actual process, 
or nudge glep41 authors to revise and get council to sign off on it 
(that chunk is somewhat unspecified procedure wise).


> > 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,

re-read it, not implying you are, what I'm stating is that no _group_ 
should have the ability to effectively force the council to 
revert/revote on a decision.  Doing so means the council loses the 
ability to have issues passed up to it, and have it agreed upon gentoo 
wide, and have people actually move forward on something.

Portage shouldn't have it, nor devrel, nor QA, nor infra (obviously my 
opinion).

And yes, I'm well aware some day a brain dead glep may get forced 
onto the portage group, in which case feel free to taunt me with those 
words.  I'll still stand by my statement from above, despite whatever 
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 
weren't sprung on you.  anoncvs/cvs ro access has been known for quite 
some time.

Restating the point, the changes were known for a freaking month prior 
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 
> mandate they accepted after they accepted this GLEP.

Which opens up an interesting question of how to get the council to do 
a re-vote on something, something that should be a _general_ process 
if implemented, not "we have to implement this, but we think it has 
issues so it should be re-examined".

~harring


[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]