avalon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Leo Simons <leosim...@apache.org>
Subject Re: [PMC:VOTE] release process for cocoon deps
Date Thu, 19 Feb 2004 18:46:54 GMT
Stephen McConnell wrote:
> 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 

>   (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.


- 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: dev-unsubscribe@avalon.apache.org
For additional commands, e-mail: dev-help@avalon.apache.org

View raw message