Re: [gentoo-dev] Email subdomain

[Brian Harring]

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 
"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.
> >
> > Probably wise, since it wasn't a friendly jab on my part (for which I
> > 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 
what's going on, then getting bit in the ass by it are to some degree 
at fault.

See the apache complaints, and ensuing emerge --news for reasoning 
behind this one (and yes, the question of how best to push the info 
out is an issue, but it still requires proactive measures from the 
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.
<snip>
> > 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).
>
> 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 
council got stuck in a nasty position, and choose what they thought
was an acceptable solution (and modified things so that scenario 
should never occur again).

Reversion based upon next day ml complaints I'm not much for since 
A) the concern was there, and they made a decision (contraversial 
or not).
B) reverting the decision is doable via existing methods, a call for 
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 
the decision opens the door for vocal minorities to try and revert 
gleps they dislike, rather then having to force their 
ideas/goals/changes through normal processes (where people can nuke 
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 
(frankly I don't think one is needed either), but it would have to be 
something that occurs on normal schedule, and would be dependant on 
the council agreeing to reopen discussion.  Considering the nature of 
this scenario, I *still* posit it's glep territory, through and 
through.

Note that last paragraph is not from any documentation- just a dump of 
what I think would be wise/best.



Everything following really should be chunked off into another thread 
to iron it out, since it's not glep41 related (although g41 is the 
catalyst for it).

> > 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. :)
> 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 
though (eg, it's not grounds for forcing a reverse of their decision 
imo).

> > 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".
>
> 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, 
at least for infra/portage their were members on the board who 
(usually) knew what was what, and could raise the concerns.

It also gave undue power to infra/portage, although that's more of a 
flaw of the TLP setup.  Current council _could_ stand to integrate 
some form of checkup from groups, but I'd be extremely unhappy if it 
was any form of actual power, versus just consulting/questioning.

Either way, modify the existing setup is fine, just be aware we're 
bound by it's rules _now_ till it's modified.
~harring