The subject of this message starts with [PMC:VOTE], however, I don't see anything to vote on.
"Proposal: if working and thoroughly tested (with verifiable results of course) versions of [this specific package list] are produced, lets agree to release them even if their documentation may not be exactly what we would like it to be."
that's the vote.
I don't see a release manager, a release plan, or even a release candidate.
correct. None of those exist at this point. Carsten raised concerns about figuring all of that out and then blocking on this stuff...
"The last time I tried it (and you tried it as well) it all failed because of a veto for the release as someone said "There are no docs, I don't know what it's all about and I don't like it". Or something similar. And I don't want to go through this again. "
The vote is about not going "through [that] again".
However, I did see a generic statement suggesting Avalon adopt the principal of releasing undocumented code. Is that the subject of the vote?
no, this is not about principle, it is about pragmatism. It is about agreeing that we bend the principle of "pristine" documentation in the best interest of project interoperability, in this specific case.
Surely you'll remember the months of excalibur phase I, II, III, IV, V, Pi^2 release talks, and how a lot of that ultimately blocked on documentation "requirements"? That was extremely frustrating. The problem is that while people like Berin or me or Carsten pop up every now and then who are perfectly willing to do lots of work to, in this case, make cocoon a better product and avalon a more valuable dependency for cocoon to have, but don't feel like complying with vague "release quality principles" and the squabble surrounding those.
Once again, the thought behind the vote is
let's adopt more *pragmatism*, in this *particular instance*, in the interest of *co-operation*
The lack of documentation simply reflects a lack of sufficient interest relative to the code.
no, the lack of documentation reflects a lack of sufficient interest relative to the documentation. There is an interest in the code. Carsten's "cry for release" message is sufficient indication of that interest, don't you think?
IMO the more import question is what we should be doing to address the viability of the code in question.
I don't want to go through all the hassle to reach consensus on that right now (again! We've been through all this! Must we really spend hours discussing all that every three months?).
Is there interests within the Avalon community in maintaining the code or not.
yes, there is. But there seems to be little to no interest in maintaining documentation that complies with the vague "release quality principles".
(a) is the package relevant to Avalon
yes. Everything irrelevant was chucked out, remember? We decided on this already. Let's not decide again.
(b) is the Avalon dev community ready/willing/able to
support the package
yes! Again, we went through a long and painful process, and every time the answer was no we took action. Can we *please* not rehash all that?
But support as in writing end user tutorials is not always needed dude. The target audience for some of these packages are avalon experts who can just read the source. They don't need hand-holding.
----
part of the problem is precisely having to hold these discussions again and again and again. No need to veto: you can discuss things to death.
-- cheers,
- Leo Simons
----------------------------------------------------------------------- Weblog -- http://leosimons.com/ IoC Component Glue -- http://jicarilla.org/ Articles & Opinions -- http://articles.leosimons.com/ ----------------------------------------------------------------------- "We started off trying to set up a small anarchist community, but people wouldn't obey the rules." -- Alan Bennett
--------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
