1 |
On Sat, Nov 19, 2005 at 04:46:51PM -0600, Lance Albertson wrote: |
2 |
> Brian Harring wrote: |
3 |
> > It's a crazy notion, but y'all could've commented in the *TWO* months |
4 |
> > that this glep has been percolating, "yo, what do you want from an |
5 |
> > infra standpoint?". |
6 |
> > |
7 |
> > Or implemented anoncvs in the meantime, thus nuking the main request |
8 |
> > that's being made of infra. |
9 |
> |
10 |
> What was posted two months ago is not the same as was posted a day |
11 |
> before the vote. I didn't see a problem with the original glep from an |
12 |
> infra POV, thus why I didn't say much about it. |
13 |
|
14 |
Email wise, you're right- the basic issue of anoncvs/cvs ro access for |
15 |
ATs however has been in the glep from the beginning (regardless of the |
16 |
glep having a minimal req tacked into it). |
17 |
|
18 |
That said, the subdomain bit has been available since the oct council |
19 |
meeting. Not something that was particularly sprung, although grounds |
20 |
for arguing that it wasn't pushed out in the best manner. |
21 |
|
22 |
That still doesn't address my point about the basic need of the glep, |
23 |
anoncvs/cvs ro being known. |
24 |
|
25 |
> > It is your guys responsibility to keep up to date on what's underway. |
26 |
> > Portage devs do it, arches do it, infra is no different. |
27 |
> > |
28 |
> > That's why you're on this ml- that is why gleps get sent to this ml- so |
29 |
> > that all of the various groups can weigh in. |
30 |
> |
31 |
> The revised GLEP in question was posted a day before the vote. I was |
32 |
> watching it, though I didn't get a chance to read through the whole GLEP |
33 |
> for the changes at the time since I was busy with real life issues. This |
34 |
> is why I stated in an email [1] that day that they should postpone |
35 |
> voting on it. |
36 |
> [1] http://marc.theaimsgroup.com/?l=gentoo-dev&m=113199543120777&w=2 |
37 |
|
38 |
Reading through it, it reads more like a comment about the process. |
39 |
It's also not an explicit request that it be delayed, which I'll |
40 |
assume is just me misreading it. |
41 |
|
42 |
> > You guys want the glep changed, either ask hparker and crew nicely, or |
43 |
> > submit your own glep. You've had time to be involved, and you've |
44 |
> > admitted you saw but did not even comment "we need to review this, |
45 |
> > it must be delayed". |
46 |
> |
47 |
> Considering how the revised GLEP went through without ANY discussion |
48 |
> prior to the vote, I don't see why we need to. That is an issue of the |
49 |
> procedure used to to get this GLEP approved which wasn't done correctly. |
50 |
> I have yet to see a valid reason for pushing ahead for the vote (and |
51 |
> yes, I read the log.. see my comments in previous emails about that |
52 |
> logic they used). |
53 |
|
54 |
Said hole has been closed; what I'm stating is that y'all should work |
55 |
through what's available rather then a forced re-vote. See tail end |
56 |
of email for reasoning. |
57 |
|
58 |
> > I see this mainly as infra/trustees not watching the ML. |
59 |
> |
60 |
> What does trustees have to do with this GLEP? And yes, I was watching |
61 |
> the ML, but giving me 24hr to respond to a GLEP revision before a vote |
62 |
> is not reasonable. |
63 |
|
64 |
Knowing what the revisions where going to be (previous meeting) makes |
65 |
the 24 hour comment a bit off. |
66 |
|
67 |
> > Frankly it seems like y'all didn't pay attention, and got caught with |
68 |
> > your pants down. |
69 |
> |
70 |
> Thats not the case, we got a revised GLEP one day before the vote and |
71 |
> didn't have a chance to reply reasonably. |
72 |
|
73 |
Email is about the only snafu out of this whole thing that is |
74 |
reasonably questionable imo. Concerns about load on lark, handling |
75 |
the new users, etc, no, as I stated, this glep has been around for 2 |
76 |
months without infra asking what's required. |
77 |
|
78 |
That's the crux of the "caught with the pants down". The fact that |
79 |
the initial glep could've passed, and still there would be |
80 |
complaints/issues brought up (beyond email concerns) afterwards |
81 |
because people didn't pay attention. |
82 |
|
83 |
> > Sucks, but too damn bad. |
84 |
> |
85 |
> I'm not going to reply to that. |
86 |
|
87 |
Probably wise, since it wasn't a friendly jab on my part (for which I |
88 |
should be duly flogged). |
89 |
|
90 |
> > And no... bitching about the window for the revision isn't really |
91 |
> > valid, since the requested revisions to the glep from the council have |
92 |
> > been known for a month already (again, more then reasonable time to |
93 |
> > know what is afoot). |
94 |
> |
95 |
> Where was it stated that it was posted and was being discussed? Just |
96 |
> because it was stated in a meeting log and was committed in cvs doesn't |
97 |
> mean I need to read cvs changelogs. I expect the information about the |
98 |
> GLEP i need to know about to be in the GLEP and that the revised GLEP to |
99 |
> be sent with ample time before the meeting at hand. This was not done |
100 |
> and this is why I'm frustrated with the situation. |
101 |
|
102 |
Again.. aside from email, the info's been out there. |
103 |
|
104 |
|
105 |
> We have yet to figure out how we're going to do this. |
106 |
> |
107 |
> > Email subdomain? Go through the channels everyone else has to. |
108 |
> |
109 |
> Huh? |
110 |
|
111 |
Specifically reverting/changing a glep. See glep1 for actual process, |
112 |
or nudge glep41 authors to revise and get council to sign off on it |
113 |
(that chunk is somewhat unspecified procedure wise). |
114 |
|
115 |
|
116 |
> > Reversion is not an option from where I'm sitting, regardless of the |
117 |
> > power infra wields over gentoo or how much y'all may dislike the glep. |
118 |
> > Change it via the methods available, rather then the kicking/screaming. |
119 |
> |
120 |
> I'm not abusing our power, |
121 |
|
122 |
re-read it, not implying you are, what I'm stating is that no _group_ |
123 |
should have the ability to effectively force the council to |
124 |
revert/revote on a decision. Doing so means the council loses the |
125 |
ability to have issues passed up to it, and have it agreed upon gentoo |
126 |
wide, and have people actually move forward on something. |
127 |
|
128 |
Portage shouldn't have it, nor devrel, nor QA, nor infra (obviously my |
129 |
opinion). |
130 |
|
131 |
And yes, I'm well aware some day a brain dead glep may get forced |
132 |
onto the portage group, in which case feel free to taunt me with those |
133 |
words. I'll still stand by my statement from above, despite whatever |
134 |
nasty thoughts may be running through my head. :) |
135 |
|
136 |
|
137 |
> I'm simply pointing out the fallacy of the |
138 |
> events that transpired. I feel that we should not have to implement |
139 |
> something that was posted a day before the vote. I *was* watching the |
140 |
> mailing lists and I *do* try and catch these things, and I *tried* to |
141 |
> have them postpone the vote. But as you can tell, something was |
142 |
> obviously out of sync communication wise because I didn't see this coming. |
143 |
|
144 |
*again*, beyond email concerns, the issues y'all are bringing up |
145 |
weren't sprung on you. anoncvs/cvs ro access has been known for quite |
146 |
some time. |
147 |
|
148 |
Restating the point, the changes were known for a freaking month prior |
149 |
to the vote. |
150 |
|
151 |
It's not out of the blue, nor is the cvs ro requirement. |
152 |
|
153 |
> All I'm after is this vote to be properly reconsidered because of a |
154 |
> mandate they accepted after they accepted this GLEP. |
155 |
|
156 |
Which opens up an interesting question of how to get the council to do |
157 |
a re-vote on something, something that should be a _general_ process |
158 |
if implemented, not "we have to implement this, but we think it has |
159 |
issues so it should be re-examined". |
160 |
|
161 |
~harring |