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).
LSD
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
