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 <[EMAIL PROTECTED]> 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
signature.asc
Description: OpenPGP digital signature
