On Mon, Nov 9, 2009 at 4:48 PM, Greg Stein <gst...@gmail.com> wrote: > On Mon, Nov 9, 2009 at 11:16, Leo Simons <m...@leosimons.com> wrote: >>... >> Not merit, just "binding vote". I agree that it sucks, but it is not >> something where the incubator has "gone awry", it has _always_ been >> messed up like this. >> >> Here's what I understand: >> >> 1) Apache rule: all apache releases must be made by PMCs >> 2) Apache rule: a release needs at least 3 binding +1s and more +1s than -1s > > I think those "-1s" are more where Justin in concerned, rather than a > bunch of IPMC people jumping in with *support*, providing a +1 where a > podling doesn't have enough active IPMC members. > > It's the *negative* support -- the hurdles and process and checklists, > some of which make zero sense for the particular podling. These can be > just as bad as a bunch of people jumping in with -1 votes.
Yes, it is really bad. But in some cases, what is the alternative? Given this situation: *) project has rolled a release and voted on it (+1s everywhere, yay, cool stuff!) *) one mentor has voted +1 (well done folks) *) wait for other mentors, no response *) the project comes to the general@ list to ask for additional votes *) I look at the release candidate, and I find a reasonably serious problem (usually legal crap, for example, let's say it ships LGPL code) What would you expect me to do at that point? This is a pretty common situation, and it sucks to be in it, for everyone. Some options: 1) don't say anything, let someone else deal with it 2) explain the problem, don't vote. This typically results in the vote stalling (because no-one else is going to vote +1 after I've pointed out the problem). 3) explain the problem, vote -1. This typically is enough to kill the vote (because no-one else is going to vote +1 after I voted -1). 4) don't say anything, vote +1, claim ignorance later if someone points out the problems. 5) explain the problem, vote +1, ask that the project fixes it later (but can't claim ignorance...). a) one of the above, and also go poke the AWOL mentors for not doing their part (usually followed by mentor resigning, or staying AWOL) I would like to have option #5 be a realistic option, but it requires that I have some ability to do a legal risk assessment (and a brief to take those risks), which I don't. So usually I go for #2 or #3. That's not me being a pencil-licking process-loving bureaucrat, it is me trying to make the best of a messed-up situation. I can try very hard to write my e-mails nicely (and I do), but usually at this point in the time the EDUCATION is just not well-received because it is tied to NOT ALLOWING THE RELEASE. There is no carrot, just a stick. I don't know what Justin was talking about, but I will bet you that a significant part of the friction that incubating projects experience is due to some variant of the above scenario [1]. Can you think of a way to fix the mess? cheers, Leo [1] That, and AWOL mentors --------------------------------------------------------------------- To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
