You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@avalon.apache.org by Leo Simons <le...@apache.org> on 2004/02/19 17:03:46 UTC
[PMC:VOTE] release process for cocoon deps
Hi gang!
Cocoon (arguably one of the biggest and most important "clients" for
avalon) is using CVS drops of these projects:
excalibur-component
excalibur-sourceresolve
excalibur-store
excalibur-xmlutil
fortress-container
fortress-tools
excalibur-logger
This is an undesirable situation.
Previously, release of some of these components was blocked because of a
lack of documentation. The net result is that there is still no
documentation, cocoon is using custom-built packages, and many cocoon
people don't feel like coming near avalon because there won't be much
oppurtunity to benefit from the work they do here (which is, simply put,
not very likely to be on documentation).
That's also an undesirable situation.
So lets loosen those documentation requirements a little.
Proposal: if working and thoroughly tested (with verifiable results of
course) versions of the packages mentioned above are produced, lets
agree to release them even if their documentation may not be exactly
what we would like it to be.
I think the only alternative is to let these packages die a slow and
painful death. We'll lose one of our biggest clients.
--
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
RE: [PMC:VOTE] release process for cocoon deps
Posted by Leo Sutic <le...@inspireinfrastructure.com>.
> From: Stephen McConnell [mailto:mcconnell@apache.org]
>
> while Leo is jumping in and doing something about the build - will
> Leo or anyone else be interested and committed to maintaining these
> things?
Well, you have one person willing to get them compilable. (Me.)
It's not much, but hey, it is a start.
(I think this is an irrelevant question, see below.)
> One way of eliminating this problem is to look at the packages in
> question and address the bigger question concerning
> synchronization with Avalon's direction.
Yes, but here you are starting a much bigger question that will
take the major part of forever to resolve. What is Avalon's
direction? Really, have we reached consensus on it?
One could make an argument that before *anything* goes into CVS -
and that includes any development of Merlin - we must have reached
agreement on the direction of Avalon. But that would be impractical,
so we don't have such a requirement. Because...
*Any* action, be it a spell check or massively new features occur
in the context of some greater question - should I fix this spell
check in the Javadocs for this class, or should take one step back,
refactor and just remove the class altogether? Should I sacrifice
backwards compatibility here or allow for pluggability? What effects
will this architectural decision have on the common component model?
Should this feature even go into Avalon? And on and on and on...
Worse, that greater question is in turn just a part of something even
greater - does backwards compat make sense here in the context of the
roadmap (what roadmap, based on what consensus?)?
However, if we try to solve the big questions, we'll *never* get
*anywhere*.
Sometimes, you just have to *make a decision*, one way or the other,
because...
...there's not enough knowledge to tackle the bigger question.
...there's no time to tackle the bigger question.
We can debate the existence of these packages in the avalon repo
endlessly, and we can debate the bigger question of continued existence
of Avalon as well - why should we exist as a TLP in Apache? Then we
can go on to discuss the meaning of life and whether our precious time
on Earth is best spent writing long rambling letters to a mailing list.
The alternative is to just acknowledge that there is a need to
get a release out, because these packages are used and needed, and
just *get on with it*.
I have a vague memory of a story about a philosopher that starved
to death even though he had plenty of food in front of him, because
he kept analyzing his actions. "Shall I eat? Must first solve the
question of mind/body duality... but then I must solve the question
of whether the food in front of me is real, and not just an
illusion..."
Sometimes you just have to skip the bigger question.
Like Carsten asked, would you be comfortable with halting *any
and all* development of Merlin until we have completely solved the
issue with metadata, a common component model, and the direction
of Avalon?
/LS
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@avalon.apache.org
For additional commands, e-mail: dev-help@avalon.apache.org
Re: [PMC:VOTE] release process for cocoon deps
Posted by Stephen McConnell <mc...@apache.org>.
Carsten Ziegeler wrote:
> Sorry but I really have the perception that you are blocking everything
> that isn't related to your work.
Carsten:
You want Avalon "the community" to release some packages. To me that
implies some degree of responsibility on this community concerning
maintenance. We "the community" should not be releasing products we
don't maintain. The very fact that the build fails for sourceresolver,
store, logging and component suggests that there is a issue concerning
the viability of these products. I'm concerned about that because while
Leo is jumping in and doing something about the build - will Leo or
anyone else be interested and committed to maintaining these things?
One way of eliminating this problem is to look at the packages in
question and address the bigger question concerning synchronization with
Avalon's direction. Does it really make sense to release sourceresolver
in its current form? From a strategic Avalon product position - no.
From a support position - yes. But what about reconciling these two?
I honestly hope that Avalon will sooner or later eliminate its multiple
personality disorder - and achieving that will require that we take
product releases seriously. It means addressing things like tag
inconsistencies - it means sorting out thing in Fortress so that there
is a rational path for users - it means holding a minimum threshold of
what is and is not releasable - and above all - it means working on
moving to a single component model.
Stephen.
--
|------------------------------------------------|
| Magic by Merlin |
| Production by Avalon |
| |
| http://avalon.apache.org/merlin |
| http://dpml.net/merlin/distributions/latest |
|------------------------------------------------|
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@avalon.apache.org
For additional commands, e-mail: dev-help@avalon.apache.org
RE: [PMC:VOTE] release process for cocoon deps
Posted by Carsten Ziegeler <cz...@s-und-n.de>.
Stephen McConnell wrote:
>
> Carsten Ziegeler wrote:
>
> > 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.
>
> Carsten - nobody is forcing anybody to do anything. You on
> the other hand have an itch - and itch relating to the
> release of a number of packages. Scratching that itch means
> doing whatever it takes to make it happen. In this particular
> scenario you going to have a bit of scratching to do because
> it will be the subject of a vote. So how about stopping the
> "I'm blocked syndrome" and just get on with it?
:-)
>
> > - I'm absolutely tired of arguing in this community
>
> The stop arguing, either work with the process here, or fork
> the content somewhere else and be happy.
>
Oh sure. Do you tell everyone who doesn't have your opinion to fork?
You might get very lonely here then.
Sorry but I really have the perception that you are blocking everything
that isn't related to your work. I'm really wondering what you would
do/think if people would start telling that the next Merlin release
can only be released if it contains more docs, can be embedded, pick
out whatever you want?
Anyways, this discussion is absolutely fruitless - let's stop it now
and help Leo if he gets into any trouble.
Thanks
Carsten
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@avalon.apache.org
For additional commands, e-mail: dev-help@avalon.apache.org
Re: [PMC:VOTE] release process for cocoon deps
Posted by Stephen McConnell <mc...@apache.org>.
Carsten Ziegeler wrote:
> 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.
Carsten - nobody is forcing anybody to do anything. You on the other
hand have an itch - and itch relating to the release of a number of
packages. Scratching that itch means doing whatever it takes to make it
happen. In this particular scenario you going to have a bit of
scratching to do because it will be the subject of a vote. So how about
stopping the "I'm blocked syndrome" and just get on with it?
> - I'm absolutely tired of arguing in this community
The stop arguing, either work with the process here, or fork the content
somewhere else and be happy.
Stephen.
--
|------------------------------------------------|
| Magic by Merlin |
| Production by Avalon |
| |
| http://avalon.apache.org/merlin |
| http://dpml.net/merlin/distributions/latest |
|------------------------------------------------|
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@avalon.apache.org
For additional commands, e-mail: dev-help@avalon.apache.org
RE: [PMC:VOTE] release process for cocoon deps
Posted by Carsten Ziegeler <cz...@s-und-n.de>.
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
Re: [PMC:VOTE] release process for cocoon deps
Posted by Leo Simons <le...@apache.org>.
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
Re: [PMC:VOTE] release process for cocoon deps
Posted by Stephen McConnell <mc...@apache.org>.
Leo:
The subject of this message starts with [PMC:VOTE], however, I don't see
anything to vote on. I don't see a release manager, a release plan, or
even a release candidate. However, I did see a generic statement
suggesting Avalon adopt the principal of releasing undocumented code.
Is that the subject of the vote?
I hope not! Lets be clear about a few things - lowering the quality
criteria for a release for Cocoon will not help Cocoon and it will not
help Avalon. The lack of documentation simply reflects a lack of
sufficient interest relative to the code. IMO the more import question
is what we should be doing to address the viability of the code in
question. Is there interests within the Avalon community in maintaining
the code or not. The answer to this will be different for the
individual packages.
Before considering a release - I would suggest that everyone consider
the following questions:
(a) is the package relevant to Avalon
(b) is the Avalon dev community ready/willing/able to
support the package
Cheers, Stephen.
Leo Simons wrote:
> Hi gang!
>
> Cocoon (arguably one of the biggest and most important "clients" for
> avalon) is using CVS drops of these projects:
>
> excalibur-component
> excalibur-sourceresolve
> excalibur-store
> excalibur-xmlutil
> fortress-container
> fortress-tools
> excalibur-logger
>
> This is an undesirable situation.
>
> Previously, release of some of these components was blocked because of a
> lack of documentation. The net result is that there is still no
> documentation, cocoon is using custom-built packages, and many cocoon
> people don't feel like coming near avalon because there won't be much
> oppurtunity to benefit from the work they do here (which is, simply put,
> not very likely to be on documentation).
>
> That's also an undesirable situation.
>
> So lets loosen those documentation requirements a little.
>
> Proposal: if working and thoroughly tested (with verifiable results of
> course) versions of the packages mentioned above are produced, lets
> agree to release them even if their documentation may not be exactly
> what we would like it to be.
>
> I think the only alternative is to let these packages die a slow and
> painful death. We'll lose one of our biggest clients.
>
--
|------------------------------------------------|
| Magic by Merlin |
| Production by Avalon |
| |
| http://avalon.apache.org/merlin |
| http://dpml.net/merlin/distributions/latest |
|------------------------------------------------|
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@avalon.apache.org
For additional commands, e-mail: dev-help@avalon.apache.org
Re: [PMC:VOTE] release process for cocoon deps
Posted by Niclas Hedhman <ni...@hedhman.org>.
On Friday 20 February 2004 00:03, Leo Simons wrote:
> Proposal: if working and thoroughly tested (with verifiable results of
> course) versions of the packages mentioned above are produced, lets
> agree to release them even if their documentation may not be exactly
> what we would like it to be.
+1
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@avalon.apache.org
For additional commands, e-mail: dev-help@avalon.apache.org