I am with Alan on that - Leo's comment when put in perspective equals
to "Incubator should not have any guidelines at all for the new
projects, and every vote is decided based on the people's mood at the
moment". That's probably not what he meant..?
But in any event clear guidelines including a statement that
packaging is up to the project (except for the minimal legal
requirements such as LICENSE and NOTICE files at the top) is a very
good thing as it reduces confusion and helps the incoming projects.
If you tried to use the release and it is broken, you have a ground
for -1 vote, but if you expected a Makefile in the src folder, and it
wasn't there (e.g. because the build procedure is a little more
involved than that), you probably don't.
An Incubator PMC member can still vote -1 in the later case to make a
point, but the burden of proof that the release has to be rejected
based on packaging is now on this member, not on the project. If he/
she can persuade the majority of the PMC to vote -1, that's fine too.
Andrus
On Oct 14, 2006, at 2: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)
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.
Regards,
Alan
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
