Re: [gentoo-dev] Email subdomain

[Lance Albertson]

Brian Harring wrote:

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

Where have I disputed the cvs ro access?

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

See above

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

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

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

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.

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

To me, those revisions should be stated in the GLEP. I shouldn't be
expected to look for GLEP changes in a meeting log. If I want to know
what changed to the GLEP, I look at the glep. And yes, I could have
probably looked on the GLEP site for that, but that doesn't explain why
it was pushed in without proper -dev discussion.

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

Its hard to sift through hundreds of emails a day to try and find things
like this. I expect things I need to be aware of to be labeled well or
in a proper place. And yes, we probably could/should have said something
about lark earlier, but didn't catch that before hand.

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

Most likely, see above.

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

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

I read email more that checking up on cvs or the site. If its something
important, it should be posted on -dev for discussion with proper time
involved. I admit, I could have looked up the glep.

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

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

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

See above

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

See above

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

-- 
Lance Albertson <ramereth@g.o>
Gentoo Infrastructure | Operations Manager

---
GPG Public Key:  <http://www.ramereth.net/lance.asc>
Key fingerprint: 0423 92F3 544A 1282 5AB1  4D07 416F A15D 27F4 B742

ramereth/irc.freenode.net