avalon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Carsten Ziegeler" <cziege...@s-und-n.de>
Subject RE: [PMC:VOTE] release process for cocoon deps
Date Fri, 20 Feb 2004 08:36:32 GMT
And here is this famous discussion again. Sigh.

Two simple statements:
- avalon is open source. if someone things that something is wrong
  (e.g. the docs) then this person should change it (scratching
  an itch) and by now way this person should try to force others
  to do it.
- I'm absolutely tired of arguing in this community and I really thank
  Leo for helping!

One simple question:
- Stephen, how do you vote on this? 

Carsten

> -----Original Message-----
> From: news [mailto:news@sea.gmane.org] On Behalf Of Leo Simons
> Sent: Thursday, February 19, 2004 7:47 PM
> To: dev@avalon.apache.org
> Subject: Re: [PMC:VOTE] release process for cocoon deps
> 
> 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 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: dev-unsubscribe@avalon.apache.org For 
> additional commands, e-mail: dev-help@avalon.apache.org
> 
> 


---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@avalon.apache.org
For additional commands, e-mail: dev-help@avalon.apache.org


Mime
View raw message