incubator-general mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Leo Simons <>
Subject Re: Insanity (of the release process)
Date Mon, 09 Nov 2009 17:51:19 GMT
On Mon, Nov 9, 2009 at 4:48 PM, Greg Stein <> wrote:
> On Mon, Nov 9, 2009 at 11:16, Leo Simons <> 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

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?



[1] That, and AWOL mentors

To unsubscribe, e-mail:
For additional commands, e-mail:

View raw message