incubator-general mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Leo Simons <>
Subject Re: Release Requirements
Date Sun, 15 Oct 2006 14:23:34 GMT
On Oct 14, 2006, at 8:12 PM, Alan D. Cabrera wrote:
> On Oct 13, 2006, at 12:16 PM, Leo Simons wrote:
>> On Oct 12, 2006, at 5:13 PM, Noel J. Bergman wrote:
>>> Can we agree that regardless of which style one might prefer the  
>>> packaging,
>>> there are multiple valid approaches, and that this level of  
>>> difference
>>> should not be a release criteria for the Incubator?
>> ASF release processes work because people can vote however they  
>> want. I don't want to create a *rule* that says people that vote  
>> can't vote in some way for some reason.
> Do I understand your statement correctly in that you think that  
> it's perfectly ok for people from the _Incubator PMC_ to vote  
> against a release because they prefer camel case names to those  
> whose parts are separated by underscores?  (I have used a trite  
> example to make my point)

Short answer: yes.

Long answer: you're twisting "should not have rule that [A] is not  
ok" into "[A] is perfectly ok". It isn't a real-world example. If  
anyone on the incubator PMC would vote that way for that reason, then  
that is a problem to solve (at that point).

The ASF has (unfortunately, I would say) some amount of hierarchical  
structure, encoded in its bylaws, which have some amount of  
"absolute" authority. Eg, giving another silly example, the incubator  
PMC chair can shut down any or all incubating projects, without prior  
notice, without prior consultation with its PMC or the wider  
community. Such a thing doesn't happen in practice, but everywhere we  
write rules we should be concious not to conflict with that structure.

> It seems to me that Noel's comment that technical decisions are  
> outside the realm of the Incubator PMC release votes and that the  
> place to chime in is at the project level, not at the Incubator PMC  
> level, is perfectly reasonable.

Yes it is. But that's not a rule. I, as an example of a PMC member,  
will not +1 a release I have strong issues with, whether those issues  
are technical or not.

As an example, I won't +1 a release consisting of non-compileable  
source in a non-existent programming language with documentation  
claiming it is the best thing since sliced bread. I would happily  
ignore any policy that states I'm to ignore any references to sliced  
bread when placing a vote.

As another example, I will happily -1 a release for some kind of web  
framework or application, if, while looking at it, I come across some  
sort of painful potential security vulnerability, and I would likely  
not even mention the specific reason in public (and now we're getting  
realistic, since this has happened once).

When I said "ASF release processes work because people can vote  
however they want", I left out a lot of details (since you can write  
a book or two about the details). As a final example, I have earned  
my position on the incubator PMC, and earned it only because I'm  
trusted to use my vote responsibly. There's no rule needed to make me  
"behave" (except perhaps a "no party policy" at apachecon hotels, but  
that's getting off-topic).


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

View raw message