You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@avalon.apache.org by Berin Loritsch <bl...@apache.org> on 2002/12/04 05:37:42 UTC
How to move forward?
We need to make a branch in CVS to seperate new development from
maintenance efforts on the old framework.
The question is do we make the 4.1 code the branch and continue new
efforts in the CVS HEAD or vice versa.
Thoughts?
---------------------------------------------
Introducing NetZero Long Distance
1st month Free!
Sign up today at: www.netzerolongdistance.com
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: How to move forward?
Posted by Berin Loritsch <bl...@apache.org>.
Peter Donald wrote:
> On Wed, 4 Dec 2002 15:37, Berin Loritsch wrote:
>
>>We need to make a branch in CVS to seperate new development from
>>maintenance efforts on the old framework.
>>
>>The question is do we make the 4.1 code the branch and continue new
>>efforts in the CVS HEAD or vice versa.
>>
>>Thoughts?
>
>
> Develope in proposal/blah where blah is some random code name or color ie red.
> I assume there will be multiple proposals going on in which case we can get
> things like;
>
> proposals/red
> proposals/blue
> proposals/green
>
> when one of them looks like it is a winner and has enough momentum split off a
> new CVS then.
>
-1. We need one repository with one community and one consensus.
---------------------------------------------
Introducing NetZero Long Distance
1st month Free!
Sign up today at: www.netzerolongdistance.com
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: [VOTE] Creation of an "avalon" CVS repository for new Avalon5
codebase (Re: How to move forward?)
Posted by Stephen McConnell <mc...@apache.org>.
Nicola Ken Barozzi wrote:
>
>
> Noel J. Bergman wrote:
>
>> I assume there will be multiple proposals going on
>> in which case we can get things like;
>> proposals/red
>> proposals/blue
>> proposals/green
>> when one of them looks like it is a winner and has enough
>> momentum split off a new CVS then.
>>
>>
>> I've read Rules for Revolutionaries, too. But isn't the entire point of
>> this exercise to move forward with ONE voice? I don't believe that
>> institutionalizing factions is the best way to address that issue.
>
>
> Agreed.
>
>> The more I read the discussions here, the more it seems to me that
>> the only
>> thing that is going to get this community moving forward in unison is to
>> have a single community container (scalable and profiled) under an
>> Avalon
>> CVS module, and preserve avalon-phoenix, avalon-excalibur/merlin, et
>> al, for
>> Avalon 4 container development while Avalon 5 is developed.
>
>
> I propose we have a new "avalon" CVS repository where to develop the
> new Avalon5 system. Things will be discussed and committed only when
> decided upon, and still eventually changed when again decided upon.
+1
>
> This will make us do a clear cut with previous development methods,
> and clearly indicate that it's a new effort and that the old will be
> nevertheless maintained.
>
> +1 for a new "avalon" CVS repository
>
> Alternatively it can be called avalon5, avalonV, aValon, avalon-5,
> avalon-ng... the important thing is that it's there.
>
"avalon" is what I think it should be (as distinct from our heritage
under jakarta-avalon)
Cheers, Steve.
--
Stephen J. McConnell
OSM SARL
digital products for a global economy
mailto:mcconnell@osm.net
http://www.osm.net
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: [VOTE] Creation of an "avalon" CVS repository for new Avalon5
codebase (Re: How to move forward?)
Posted by Leif Mortenson <le...@tanukisoftware.com>.
Nicola Ken Barozzi wrote:
> new "avalon" CVS repository
Until it has matured a but, I think it should go into the sandbox. So I am
-1
Cheers,
Leif
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: [VOTE] Creation of an "avalon" CVS repository for new Avalon5
codebase (Re: How to move forward?)
Posted by Nicola Ken Barozzi <ni...@apache.org>.
Leo Simons wrote:
> I'm amendable on an "avalon" cvs containing next-generation material,
> but we don't have any next-generation material yet. I think that the
> next-gen stuff could/should be developed in avalon-sandbox cvs as it
> makes quite clear what the status of that material is.
>
> When we are ready to start a beta cycle of some kind on sandbox material
> a new cvs might be a good idea. Until then, I think it is confusing to
> have this repo, especially as it will/should be empty.
>
> Hence I vote -1 for creating it right now.
I understand your point, and it's sensible and has good reasoning.
But IMHO we can also use the new avalon CVS instead of the sandbox dir
*exactly* with the same purpose, and have the history already there and
start from the initial commits. To make it clear we can put a WARNING
file in the main dir and in the docs there. Using the sandbox can also
confuse, since material in there can be or can also not be put in the
main repo, while here we are effectively creating the new repo. Tomcat 5
development is done in the new repo, not in a sandbox or the new one.
Just IMHO that is.
> regards,
>
> - Leo
>
> On Wed, 2002-12-04 at 10:49, Nicola Ken Barozzi wrote:
>
>>I propose we have a new "avalon" CVS repository where to develop the new
>>Avalon5 system. Things will be discussed and committed only when decided
>>upon, and still eventually changed when again decided upon.
>>
>>This will make us do a clear cut with previous development methods, and
>>clearly indicate that it's a new effort and that the old will be
>>nevertheless maintained.
>>
>>+1 for a new "avalon" CVS repository
>>
>>Alternatively it can be called avalon5, avalonV, aValon, avalon-5,
>>avalon-ng... the important thing is that it's there.
--
Nicola Ken Barozzi nicolaken@apache.org
- verba volant, scripta manent -
(discussions get forgotten, just code remains)
---------------------------------------------------------------------
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: [VOTE] Creation of an "avalon" CVS repository for new Avalon5 codebase (Re: How to move forward?)
Posted by Peter Donald <pe...@realityforge.org>.
-1 for same reasons as below.
On Wed, 4 Dec 2002 23:13, Leo Simons wrote:
> I'm amendable on an "avalon" cvs containing next-generation material,
> but we don't have any next-generation material yet. I think that the
> next-gen stuff could/should be developed in avalon-sandbox cvs as it
> makes quite clear what the status of that material is.
>
> When we are ready to start a beta cycle of some kind on sandbox material
> a new cvs might be a good idea. Until then, I think it is confusing to
> have this repo, especially as it will/should be empty.
>
> Hence I vote -1 for creating it right now.
--
Cheers,
Peter Donald
Einstein argued that there must be simplified explanations of nature, because
God is not capricious or arbitrary. No such faith comforts the software
engineer.
- Fred Brooks, Jr.
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: [VOTE] Creation of an "avalon" CVS repository for new Avalon5 codebase (Re: How to move forward?)
Posted by Peter Donald <pe...@realityforge.org>.
-1 for same reasons as below.
On Wed, 4 Dec 2002 23:13, Leo Simons wrote:
> I'm amendable on an "avalon" cvs containing next-generation material,
> but we don't have any next-generation material yet. I think that the
> next-gen stuff could/should be developed in avalon-sandbox cvs as it
> makes quite clear what the status of that material is.
>
> When we are ready to start a beta cycle of some kind on sandbox material
> a new cvs might be a good idea. Until then, I think it is confusing to
> have this repo, especially as it will/should be empty.
>
> Hence I vote -1 for creating it right now.
--
Cheers,
Peter Donald
Einstein argued that there must be simplified explanations of nature, because
God is not capricious or arbitrary. No such faith comforts the software
engineer.
- Fred Brooks, Jr.
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: [VOTE] Creation of an "avalon" CVS repository for new Avalon5 codebase (Re: How to move forward?)
Posted by Peter Donald <pe...@realityforge.org>.
-1 for same reasons as below.
On Wed, 4 Dec 2002 23:13, Leo Simons wrote:
> I'm amendable on an "avalon" cvs containing next-generation material,
> but we don't have any next-generation material yet. I think that the
> next-gen stuff could/should be developed in avalon-sandbox cvs as it
> makes quite clear what the status of that material is.
>
> When we are ready to start a beta cycle of some kind on sandbox material
> a new cvs might be a good idea. Until then, I think it is confusing to
> have this repo, especially as it will/should be empty.
>
> Hence I vote -1 for creating it right now.
--
Cheers,
Peter Donald
Einstein argued that there must be simplified explanations of nature, because
God is not capricious or arbitrary. No such faith comforts the software
engineer.
- Fred Brooks, Jr.
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: [VOTE] Creation of an "avalon" CVS repository for new Avalon5
codebase (Re: How to move forward?)
Posted by Nicola Ken Barozzi <ni...@apache.org>.
Leo Simons wrote:
> I'm amendable on an "avalon" cvs containing next-generation material,
> but we don't have any next-generation material yet. I think that the
> next-gen stuff could/should be developed in avalon-sandbox cvs as it
> makes quite clear what the status of that material is.
>
> When we are ready to start a beta cycle of some kind on sandbox material
> a new cvs might be a good idea. Until then, I think it is confusing to
> have this repo, especially as it will/should be empty.
>
> Hence I vote -1 for creating it right now.
I understand your point, and it's sensible and has good reasoning.
But IMHO we can also use the new avalon CVS instead of the sandbox dir
*exactly* with the same purpose, and have the history already there and
start from the initial commits. To make it clear we can put a WARNING
file in the main dir and in the docs there. Using the sandbox can also
confuse, since material in there can be or can also not be put in the
main repo, while here we are effectively creating the new repo. Tomcat 5
development is done in the new repo, not in a sandbox or the new one.
Just IMHO that is.
> regards,
>
> - Leo
>
> On Wed, 2002-12-04 at 10:49, Nicola Ken Barozzi wrote:
>
>>I propose we have a new "avalon" CVS repository where to develop the new
>>Avalon5 system. Things will be discussed and committed only when decided
>>upon, and still eventually changed when again decided upon.
>>
>>This will make us do a clear cut with previous development methods, and
>>clearly indicate that it's a new effort and that the old will be
>>nevertheless maintained.
>>
>>+1 for a new "avalon" CVS repository
>>
>>Alternatively it can be called avalon5, avalonV, aValon, avalon-5,
>>avalon-ng... the important thing is that it's there.
--
Nicola Ken Barozzi nicolaken@apache.org
- verba volant, scripta manent -
(discussions get forgotten, just code remains)
---------------------------------------------------------------------
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: [VOTE] Creation of an "avalon" CVS repository for new Avalon5
codebase (Re: How to move forward?)
Posted by Nicola Ken Barozzi <ni...@apache.org>.
Leo Simons wrote:
> I'm amendable on an "avalon" cvs containing next-generation material,
> but we don't have any next-generation material yet. I think that the
> next-gen stuff could/should be developed in avalon-sandbox cvs as it
> makes quite clear what the status of that material is.
>
> When we are ready to start a beta cycle of some kind on sandbox material
> a new cvs might be a good idea. Until then, I think it is confusing to
> have this repo, especially as it will/should be empty.
>
> Hence I vote -1 for creating it right now.
I understand your point, and it's sensible and has good reasoning.
But IMHO we can also use the new avalon CVS instead of the sandbox dir
*exactly* with the same purpose, and have the history already there and
start from the initial commits. To make it clear we can put a WARNING
file in the main dir and in the docs there. Using the sandbox can also
confuse, since material in there can be or can also not be put in the
main repo, while here we are effectively creating the new repo. Tomcat 5
development is done in the new repo, not in a sandbox or the new one.
Just IMHO that is.
> regards,
>
> - Leo
>
> On Wed, 2002-12-04 at 10:49, Nicola Ken Barozzi wrote:
>
>>I propose we have a new "avalon" CVS repository where to develop the new
>>Avalon5 system. Things will be discussed and committed only when decided
>>upon, and still eventually changed when again decided upon.
>>
>>This will make us do a clear cut with previous development methods, and
>>clearly indicate that it's a new effort and that the old will be
>>nevertheless maintained.
>>
>>+1 for a new "avalon" CVS repository
>>
>>Alternatively it can be called avalon5, avalonV, aValon, avalon-5,
>>avalon-ng... the important thing is that it's there.
--
Nicola Ken Barozzi nicolaken@apache.org
- verba volant, scripta manent -
(discussions get forgotten, just code remains)
---------------------------------------------------------------------
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: [VOTE] Creation of an "avalon" CVS repository for new Avalon5
codebase (Re: How to move forward?)
Posted by Leo Simons <le...@apache.org>.
I'm amendable on an "avalon" cvs containing next-generation material,
but we don't have any next-generation material yet. I think that the
next-gen stuff could/should be developed in avalon-sandbox cvs as it
makes quite clear what the status of that material is.
When we are ready to start a beta cycle of some kind on sandbox material
a new cvs might be a good idea. Until then, I think it is confusing to
have this repo, especially as it will/should be empty.
Hence I vote -1 for creating it right now.
regards,
- Leo
On Wed, 2002-12-04 at 10:49, Nicola Ken Barozzi wrote:
> I propose we have a new "avalon" CVS repository where to develop the new
> Avalon5 system. Things will be discussed and committed only when decided
> upon, and still eventually changed when again decided upon.
>
> This will make us do a clear cut with previous development methods, and
> clearly indicate that it's a new effort and that the old will be
> nevertheless maintained.
>
> +1 for a new "avalon" CVS repository
>
> Alternatively it can be called avalon5, avalonV, aValon, avalon-5,
> avalon-ng... the important thing is that it's there.
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: [VOTE] Creation of an "avalon" CVS repository for new Avalon5
codebase (Re: How to move forward?)
Posted by Leif Mortenson <le...@tanukisoftware.com>.
Nicola Ken Barozzi wrote:
> new "avalon" CVS repository
Until it has matured a but, I think it should go into the sandbox. So I am
-1
Cheers,
Leif
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: [VOTE] Creation of an "avalon" CVS repository for new Avalon5
codebase (Re: How to move forward?)
Posted by Leo Simons <le...@apache.org>.
I'm amendable on an "avalon" cvs containing next-generation material,
but we don't have any next-generation material yet. I think that the
next-gen stuff could/should be developed in avalon-sandbox cvs as it
makes quite clear what the status of that material is.
When we are ready to start a beta cycle of some kind on sandbox material
a new cvs might be a good idea. Until then, I think it is confusing to
have this repo, especially as it will/should be empty.
Hence I vote -1 for creating it right now.
regards,
- Leo
On Wed, 2002-12-04 at 10:49, Nicola Ken Barozzi wrote:
> I propose we have a new "avalon" CVS repository where to develop the new
> Avalon5 system. Things will be discussed and committed only when decided
> upon, and still eventually changed when again decided upon.
>
> This will make us do a clear cut with previous development methods, and
> clearly indicate that it's a new effort and that the old will be
> nevertheless maintained.
>
> +1 for a new "avalon" CVS repository
>
> Alternatively it can be called avalon5, avalonV, aValon, avalon-5,
> avalon-ng... the important thing is that it's there.
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: [VOTE] Creation of an "avalon" CVS repository for new Avalon5
codebase (Re: How to move forward?)
Posted by Stephen McConnell <mc...@apache.org>.
Nicola Ken Barozzi wrote:
>
>
> Noel J. Bergman wrote:
>
>> I assume there will be multiple proposals going on
>> in which case we can get things like;
>> proposals/red
>> proposals/blue
>> proposals/green
>> when one of them looks like it is a winner and has enough
>> momentum split off a new CVS then.
>>
>>
>> I've read Rules for Revolutionaries, too. But isn't the entire point of
>> this exercise to move forward with ONE voice? I don't believe that
>> institutionalizing factions is the best way to address that issue.
>
>
> Agreed.
>
>> The more I read the discussions here, the more it seems to me that
>> the only
>> thing that is going to get this community moving forward in unison is to
>> have a single community container (scalable and profiled) under an
>> Avalon
>> CVS module, and preserve avalon-phoenix, avalon-excalibur/merlin, et
>> al, for
>> Avalon 4 container development while Avalon 5 is developed.
>
>
> I propose we have a new "avalon" CVS repository where to develop the
> new Avalon5 system. Things will be discussed and committed only when
> decided upon, and still eventually changed when again decided upon.
+1
>
> This will make us do a clear cut with previous development methods,
> and clearly indicate that it's a new effort and that the old will be
> nevertheless maintained.
>
> +1 for a new "avalon" CVS repository
>
> Alternatively it can be called avalon5, avalonV, aValon, avalon-5,
> avalon-ng... the important thing is that it's there.
>
"avalon" is what I think it should be (as distinct from our heritage
under jakarta-avalon)
Cheers, Steve.
--
Stephen J. McConnell
OSM SARL
digital products for a global economy
mailto:mcconnell@osm.net
http://www.osm.net
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: [VOTE] Creation of an "avalon" CVS repository for new Avalon5
codebase (Re: How to move forward?)
Posted by Nicola Ken Barozzi <ni...@apache.org>.
Leo Sutic wrote:
>
> From: Nicola Ken Barozzi [mailto:nicolaken@apache.org]
>
> Nicola Ken Barozzi wrote:
> [...]
>
>>I propose we have a new "avalon" CVS repository where to
>
> develop the
>
>>new
>>Avalon5 system. Things will be discussed and committed only
>
> when decided
>
>>upon, and still eventually changed when again decided upon.
>>
>>This will make us do a clear cut with previous development methods,
>>and
>>clearly indicate that it's a new effort and that the old will be
>>nevertheless maintained.
>>
>>+1 for a new "avalon" CVS repository
>>
>>Alternatively it can be called avalon5, avalonV, aValon, avalon-5,
>>avalon-ng... the important thing is that it's there.
>
> Despite a feeling by some that a decision has been taken on this,
> current votes stand in a tie like this:
>
> o Creation of an "avalon" CVS repository for new Avalon5
> codebase
> +1: nicolaken, mcconnell
> +0: cziegeler
> -0: proyal
> -1: leosimons, leif
>
>
> Anyone else wants to say his?
>
>
> I think the deadlock (and the few votes) is reason enough to just hit
> the "pause" button on this voting for say, two-three days, and then
> try again. Let's have a go at the charter first, and then re-visit
> this one.
>
> Does that sound sensible?
More than sensible, I'm on the same track. :-)
> I am +1 for the new CVS (I think we should have an avalon CVS instead of
> a
> jakarta-avalon anyway), and I think that this new unified effort should
> have a CVS of its own (no need to have "proposal" directories and stuff
> like that + it doesn't make the new effort a sub-project of some
> existing module). OTOH, I am reflexively against creating "new
> playgrounds",
> maybe irrationally so. But the fact that this vote ran into a deadlock
> makes me not want to tip the balance.
I'll not put this vote in the STATUS file then myself, and wait till we
find more agreement on it. When you feel it's time to place your vote,
post it or commit it.
--
Nicola Ken Barozzi nicolaken@apache.org
- verba volant, scripta manent -
(discussions get forgotten, just code remains)
---------------------------------------------------------------------
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
RE: [VOTE] Creation of an "avalon" CVS repository for new Avalon5 codebase (Re: How to move forward?)
Posted by Leo Sutic <le...@inspireinfrastructure.com>.
> From: Nicola Ken Barozzi [mailto:nicolaken@apache.org]
>
> Nicola Ken Barozzi wrote:
> [...]
> > I propose we have a new "avalon" CVS repository where to
> develop the
> > new
> > Avalon5 system. Things will be discussed and committed only
> when decided
> > upon, and still eventually changed when again decided upon.
> >
> > This will make us do a clear cut with previous development methods,
> > and
> > clearly indicate that it's a new effort and that the old will be
> > nevertheless maintained.
> >
> > +1 for a new "avalon" CVS repository
> >
> > Alternatively it can be called avalon5, avalonV, aValon, avalon-5,
> > avalon-ng... the important thing is that it's there.
>
> Despite a feeling by some that a decision has been taken on this,
> current votes stand in a tie like this:
>
> o Creation of an "avalon" CVS repository for new Avalon5
> codebase
> +1: nicolaken, mcconnell
> +0: cziegeler
> -0: proyal
> -1: leosimons, leif
>
>
> Anyone else wants to say his?
I think the deadlock (and the few votes) is reason enough to just hit
the "pause" button on this voting for say, two-three days, and then
try again. Let's have a go at the charter first, and then re-visit
this one.
Does that sound sensible?
I am +1 for the new CVS (I think we should have an avalon CVS instead of
a
jakarta-avalon anyway), and I think that this new unified effort should
have a CVS of its own (no need to have "proposal" directories and stuff
like that + it doesn't make the new effort a sub-project of some
existing module). OTOH, I am reflexively against creating "new
playgrounds",
maybe irrationally so. But the fact that this vote ran into a deadlock
makes me not want to tip the balance.
/LS
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: [VOTE] Creation of an "avalon" CVS repository for new Avalon5
codebase (Re: How to move forward?)
Posted by Nicola Ken Barozzi <ni...@apache.org>.
Nicola Ken Barozzi wrote:
[...]
> I propose we have a new "avalon" CVS repository where to develop the new
> Avalon5 system. Things will be discussed and committed only when decided
> upon, and still eventually changed when again decided upon.
>
> This will make us do a clear cut with previous development methods, and
> clearly indicate that it's a new effort and that the old will be
> nevertheless maintained.
>
> +1 for a new "avalon" CVS repository
>
> Alternatively it can be called avalon5, avalonV, aValon, avalon-5,
> avalon-ng... the important thing is that it's there.
Despite a feeling by some that a decision has been taken on this,
current votes stand in a tie like this:
o Creation of an "avalon" CVS repository for new Avalon5
codebase
+1: nicolaken, mcconnell
+0: cziegeler
-0: proyal
-1: leosimons, leif
Anyone else wants to say his?
--
Nicola Ken Barozzi nicolaken@apache.org
- verba volant, scripta manent -
(discussions get forgotten, just code remains)
---------------------------------------------------------------------
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: [VOTE] Creation of an "avalon" CVS repository for new Avalon5
codebase (Re: How to move forward?)
Posted by Leo Simons <le...@apache.org>.
I'm amendable on an "avalon" cvs containing next-generation material,
but we don't have any next-generation material yet. I think that the
next-gen stuff could/should be developed in avalon-sandbox cvs as it
makes quite clear what the status of that material is.
When we are ready to start a beta cycle of some kind on sandbox material
a new cvs might be a good idea. Until then, I think it is confusing to
have this repo, especially as it will/should be empty.
Hence I vote -1 for creating it right now.
regards,
- Leo
On Wed, 2002-12-04 at 10:49, Nicola Ken Barozzi wrote:
> I propose we have a new "avalon" CVS repository where to develop the new
> Avalon5 system. Things will be discussed and committed only when decided
> upon, and still eventually changed when again decided upon.
>
> This will make us do a clear cut with previous development methods, and
> clearly indicate that it's a new effort and that the old will be
> nevertheless maintained.
>
> +1 for a new "avalon" CVS repository
>
> Alternatively it can be called avalon5, avalonV, aValon, avalon-5,
> avalon-ng... the important thing is that it's there.
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: [VOTE] Creation of an "avalon" CVS repository for new Avalon5
codebase (Re: How to move forward?)
Posted by Leif Mortenson <le...@tanukisoftware.com>.
Nicola Ken Barozzi wrote:
> new "avalon" CVS repository
Until it has matured a but, I think it should go into the sandbox. So I am
-1
Cheers,
Leif
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: [VOTE] Creation of an "avalon" CVS repository for new Avalon5
codebase (Re: How to move forward?)
Posted by Stephen McConnell <mc...@apache.org>.
Nicola Ken Barozzi wrote:
>
>
> Noel J. Bergman wrote:
>
>> I assume there will be multiple proposals going on
>> in which case we can get things like;
>> proposals/red
>> proposals/blue
>> proposals/green
>> when one of them looks like it is a winner and has enough
>> momentum split off a new CVS then.
>>
>>
>> I've read Rules for Revolutionaries, too. But isn't the entire point of
>> this exercise to move forward with ONE voice? I don't believe that
>> institutionalizing factions is the best way to address that issue.
>
>
> Agreed.
>
>> The more I read the discussions here, the more it seems to me that
>> the only
>> thing that is going to get this community moving forward in unison is to
>> have a single community container (scalable and profiled) under an
>> Avalon
>> CVS module, and preserve avalon-phoenix, avalon-excalibur/merlin, et
>> al, for
>> Avalon 4 container development while Avalon 5 is developed.
>
>
> I propose we have a new "avalon" CVS repository where to develop the
> new Avalon5 system. Things will be discussed and committed only when
> decided upon, and still eventually changed when again decided upon.
+1
>
> This will make us do a clear cut with previous development methods,
> and clearly indicate that it's a new effort and that the old will be
> nevertheless maintained.
>
> +1 for a new "avalon" CVS repository
>
> Alternatively it can be called avalon5, avalonV, aValon, avalon-5,
> avalon-ng... the important thing is that it's there.
>
"avalon" is what I think it should be (as distinct from our heritage
under jakarta-avalon)
Cheers, Steve.
--
Stephen J. McConnell
OSM SARL
digital products for a global economy
mailto:mcconnell@osm.net
http://www.osm.net
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: [VOTE] Creation of an "avalon" CVS repository for new Avalon5 codebase (Re: How to move forward?)
Posted by Peter Royal <pr...@apache.org>.
On Wednesday, December 4, 2002, at 04:49 AM, Nicola Ken Barozzi wrote:
> +1 for a new "avalon" CVS repository
>
> Alternatively it can be called avalon5, avalonV, aValon, avalon-5,
> avalon-ng... the important thing is that it's there.
I'm -0 on this.. what's wrong with the sandbox?
I do like Peter D's idea of having multiple proposal directories. Yes,
there will be one final solution chosen, but I don't think that should
preclude having multiple trees and approaches to view and hack on
during that decision making process. That way radical ideas can have a
place to be demonstrated to the community before the community adopting
them.
-peter
--
peter royal -> proyal@apache.org
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: [VOTE] Creation of an "avalon" CVS repository for new Avalon5 codebase (Re: How to move forward?)
Posted by Peter Royal <pr...@apache.org>.
On Wednesday, December 4, 2002, at 04:49 AM, Nicola Ken Barozzi wrote:
> +1 for a new "avalon" CVS repository
>
> Alternatively it can be called avalon5, avalonV, aValon, avalon-5,
> avalon-ng... the important thing is that it's there.
I'm -0 on this.. what's wrong with the sandbox?
I do like Peter D's idea of having multiple proposal directories. Yes,
there will be one final solution chosen, but I don't think that should
preclude having multiple trees and approaches to view and hack on
during that decision making process. That way radical ideas can have a
place to be demonstrated to the community before the community adopting
them.
-peter
--
peter royal -> proyal@apache.org
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: [VOTE] Creation of an "avalon" CVS repository for new Avalon5
codebase (Re: How to move forward?)
Posted by Nicola Ken Barozzi <ni...@apache.org>.
Carsten Ziegeler wrote:
> Nicola Ken Barozzi wrote:
>
>>avalon-sandbox was created nevertheless, and IMHO it creates less
>>confusion.
>>
>>Tomcat or Apache for example use new CVSes for new versions, it's not
>>something that necessarily affects compatibility.
>>
>
> Yes, you know this and I know this, but I think not everyone - especially
> users don't.
> But as I said (tried to say?) - a repository is ok for me.
Yup, I've counted your +0.
I took the opportunity to reply to your mail to expose my view a bit
better. Thank you :-)
--
Nicola Ken Barozzi nicolaken@apache.org
- verba volant, scripta manent -
(discussions get forgotten, just code remains)
---------------------------------------------------------------------
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: [VOTE] Creation of an "avalon" CVS repository for new Avalon5
codebase (Re: How to move forward?)
Posted by Nicola Ken Barozzi <ni...@apache.org>.
Carsten Ziegeler wrote:
> Nicola Ken Barozzi wrote:
>
>>avalon-sandbox was created nevertheless, and IMHO it creates less
>>confusion.
>>
>>Tomcat or Apache for example use new CVSes for new versions, it's not
>>something that necessarily affects compatibility.
>>
>
> Yes, you know this and I know this, but I think not everyone - especially
> users don't.
> But as I said (tried to say?) - a repository is ok for me.
Yup, I've counted your +0.
I took the opportunity to reply to your mail to expose my view a bit
better. Thank you :-)
--
Nicola Ken Barozzi nicolaken@apache.org
- verba volant, scripta manent -
(discussions get forgotten, just code remains)
---------------------------------------------------------------------
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: [VOTE] Creation of an "avalon" CVS repository for new Avalon5
codebase (Re: How to move forward?)
Posted by Nicola Ken Barozzi <ni...@apache.org>.
Carsten Ziegeler wrote:
> Nicola Ken Barozzi wrote:
>
>>avalon-sandbox was created nevertheless, and IMHO it creates less
>>confusion.
>>
>>Tomcat or Apache for example use new CVSes for new versions, it's not
>>something that necessarily affects compatibility.
>>
>
> Yes, you know this and I know this, but I think not everyone - especially
> users don't.
> But as I said (tried to say?) - a repository is ok for me.
Yup, I've counted your +0.
I took the opportunity to reply to your mail to expose my view a bit
better. Thank you :-)
--
Nicola Ken Barozzi nicolaken@apache.org
- verba volant, scripta manent -
(discussions get forgotten, just code remains)
---------------------------------------------------------------------
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
RE: [VOTE] Creation of an "avalon" CVS repository for new Avalon5 codebase (Re: How to move forward?)
Posted by "Noel J. Bergman" <no...@devtech.com>.
> > Tomcat or Apache for example use new CVSes for new versions, it's not
> > something that necessarily affects compatibility.
> you know this and I know this, but I think not everyone
> - especially users don't.
Such users generally don't care about CVS repositories at all. They care
about mailing lists, web sites, and release packages.
--- Noel
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
RE: [VOTE] Creation of an "avalon" CVS repository for new Avalon5 codebase (Re: How to move forward?)
Posted by "Noel J. Bergman" <no...@devtech.com>.
> > Tomcat or Apache for example use new CVSes for new versions, it's not
> > something that necessarily affects compatibility.
> you know this and I know this, but I think not everyone
> - especially users don't.
Such users generally don't care about CVS repositories at all. They care
about mailing lists, web sites, and release packages.
--- Noel
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
RE: [VOTE] Creation of an "avalon" CVS repository for new Avalon5 codebase (Re: How to move forward?)
Posted by "Noel J. Bergman" <no...@devtech.com>.
> > Tomcat or Apache for example use new CVSes for new versions, it's not
> > something that necessarily affects compatibility.
> you know this and I know this, but I think not everyone
> - especially users don't.
Such users generally don't care about CVS repositories at all. They care
about mailing lists, web sites, and release packages.
--- Noel
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
RE: [VOTE] Creation of an "avalon" CVS repository for new Avalon5 codebase (Re: How to move forward?)
Posted by Carsten Ziegeler <cz...@s-und-n.de>.
Nicola Ken Barozzi wrote:
>
> avalon-sandbox was created nevertheless, and IMHO it creates less
> confusion.
>
> Tomcat or Apache for example use new CVSes for new versions, it's not
> something that necessarily affects compatibility.
>
Yes, you know this and I know this, but I think not everyone - especially
users don't.
But as I said (tried to say?) - a repository is ok for me.
Carsten
Carsten Ziegeler
Open Source Group, S&N AG
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
RE: [VOTE] Creation of an "avalon" CVS repository for new Avalon5 codebase (Re: How to move forward?)
Posted by Carsten Ziegeler <cz...@s-und-n.de>.
Nicola Ken Barozzi wrote:
>
> avalon-sandbox was created nevertheless, and IMHO it creates less
> confusion.
>
> Tomcat or Apache for example use new CVSes for new versions, it's not
> something that necessarily affects compatibility.
>
Yes, you know this and I know this, but I think not everyone - especially
users don't.
But as I said (tried to say?) - a repository is ok for me.
Carsten
Carsten Ziegeler
Open Source Group, S&N AG
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
RE: [VOTE] Creation of an "avalon" CVS repository for new Avalon5 codebase (Re: How to move forward?)
Posted by Carsten Ziegeler <cz...@s-und-n.de>.
Nicola Ken Barozzi wrote:
>
> avalon-sandbox was created nevertheless, and IMHO it creates less
> confusion.
>
> Tomcat or Apache for example use new CVSes for new versions, it's not
> something that necessarily affects compatibility.
>
Yes, you know this and I know this, but I think not everyone - especially
users don't.
But as I said (tried to say?) - a repository is ok for me.
Carsten
Carsten Ziegeler
Open Source Group, S&N AG
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: [VOTE] Creation of an "avalon" CVS repository for new Avalon5
codebase (Re: How to move forward?)
Posted by Nicola Ken Barozzi <ni...@apache.org>.
Carsten Ziegeler wrote:
> Nicola Ken Barozzi wrote:
>
>>I propose we have a new "avalon" CVS repository where to develop the new
>>Avalon5 system. Things will be discussed and committed only when decided
>>upon, and still eventually changed when again decided upon.
>>
>>This will make us do a clear cut with previous development methods, and
>>clearly indicate that it's a new effort and that the old will be
>>nevertheless maintained.
>>
>>+1 for a new "avalon" CVS repository
>>
>
> +0 - I'm not against it, but I'm not sure if it is worth creating
> a new repository, why not making a directory inside the existing
> repository with the same structure?
> Creating a new repository has the effect that people will think
> that it is something new (and incompatible) whether it is or not.
> So, I'm +1 for a separate directory within our repository.
avalon-sandbox was created nevertheless, and IMHO it creates less confusion.
Tomcat or Apache for example use new CVSes for new versions, it's not
something that necessarily affects compatibility.
apache-1.2/
apache-1.3/
httpd-2.0/
jakarta-tomcat/
jakarta-tomcat-4.0/
jakarta-tomcat-5/
>>Alternatively it can be called avalon5, avalonV, aValon, avalon-5,
>>avalon-ng... the important thing is that it's there.
>
>
> That's true.
--
Nicola Ken Barozzi nicolaken@apache.org
- verba volant, scripta manent -
(discussions get forgotten, just code remains)
---------------------------------------------------------------------
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: [VOTE] Creation of an "avalon" CVS repository for new Avalon5
codebase (Re: How to move forward?)
Posted by Nicola Ken Barozzi <ni...@apache.org>.
Carsten Ziegeler wrote:
> Nicola Ken Barozzi wrote:
>
>>I propose we have a new "avalon" CVS repository where to develop the new
>>Avalon5 system. Things will be discussed and committed only when decided
>>upon, and still eventually changed when again decided upon.
>>
>>This will make us do a clear cut with previous development methods, and
>>clearly indicate that it's a new effort and that the old will be
>>nevertheless maintained.
>>
>>+1 for a new "avalon" CVS repository
>>
>
> +0 - I'm not against it, but I'm not sure if it is worth creating
> a new repository, why not making a directory inside the existing
> repository with the same structure?
> Creating a new repository has the effect that people will think
> that it is something new (and incompatible) whether it is or not.
> So, I'm +1 for a separate directory within our repository.
avalon-sandbox was created nevertheless, and IMHO it creates less confusion.
Tomcat or Apache for example use new CVSes for new versions, it's not
something that necessarily affects compatibility.
apache-1.2/
apache-1.3/
httpd-2.0/
jakarta-tomcat/
jakarta-tomcat-4.0/
jakarta-tomcat-5/
>>Alternatively it can be called avalon5, avalonV, aValon, avalon-5,
>>avalon-ng... the important thing is that it's there.
>
>
> That's true.
--
Nicola Ken Barozzi nicolaken@apache.org
- verba volant, scripta manent -
(discussions get forgotten, just code remains)
---------------------------------------------------------------------
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: [VOTE] Creation of an "avalon" CVS repository for new Avalon5
codebase (Re: How to move forward?)
Posted by Nicola Ken Barozzi <ni...@apache.org>.
Carsten Ziegeler wrote:
> Nicola Ken Barozzi wrote:
>
>>I propose we have a new "avalon" CVS repository where to develop the new
>>Avalon5 system. Things will be discussed and committed only when decided
>>upon, and still eventually changed when again decided upon.
>>
>>This will make us do a clear cut with previous development methods, and
>>clearly indicate that it's a new effort and that the old will be
>>nevertheless maintained.
>>
>>+1 for a new "avalon" CVS repository
>>
>
> +0 - I'm not against it, but I'm not sure if it is worth creating
> a new repository, why not making a directory inside the existing
> repository with the same structure?
> Creating a new repository has the effect that people will think
> that it is something new (and incompatible) whether it is or not.
> So, I'm +1 for a separate directory within our repository.
avalon-sandbox was created nevertheless, and IMHO it creates less confusion.
Tomcat or Apache for example use new CVSes for new versions, it's not
something that necessarily affects compatibility.
apache-1.2/
apache-1.3/
httpd-2.0/
jakarta-tomcat/
jakarta-tomcat-4.0/
jakarta-tomcat-5/
>>Alternatively it can be called avalon5, avalonV, aValon, avalon-5,
>>avalon-ng... the important thing is that it's there.
>
>
> That's true.
--
Nicola Ken Barozzi nicolaken@apache.org
- verba volant, scripta manent -
(discussions get forgotten, just code remains)
---------------------------------------------------------------------
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
RE: [VOTE] Creation of an "avalon" CVS repository for new Avalon5 codebase (Re: How to move forward?)
Posted by Carsten Ziegeler <cz...@s-und-n.de>.
Nicola Ken Barozzi wrote:
>
> I propose we have a new "avalon" CVS repository where to develop the new
> Avalon5 system. Things will be discussed and committed only when decided
> upon, and still eventually changed when again decided upon.
>
> This will make us do a clear cut with previous development methods, and
> clearly indicate that it's a new effort and that the old will be
> nevertheless maintained.
>
> +1 for a new "avalon" CVS repository
>
+0 - I'm not against it, but I'm not sure if it is worth creating
a new repository, why not making a directory inside the existing
repository with the same structure?
Creating a new repository has the effect that people will think
that it is something new (and incompatible) whether it is or not.
So, I'm +1 for a separate directory within our repository.
> Alternatively it can be called avalon5, avalonV, aValon, avalon-5,
> avalon-ng... the important thing is that it's there.
That's true.
Carsten
Carsten Ziegeler
Open Source Group, S&N AG
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: [VOTE] Creation of an "avalon" CVS repository for new Avalon5 codebase (Re: How to move forward?)
Posted by Peter Royal <pr...@apache.org>.
On Wednesday, December 4, 2002, at 04:49 AM, Nicola Ken Barozzi wrote:
> +1 for a new "avalon" CVS repository
>
> Alternatively it can be called avalon5, avalonV, aValon, avalon-5,
> avalon-ng... the important thing is that it's there.
I'm -0 on this.. what's wrong with the sandbox?
I do like Peter D's idea of having multiple proposal directories. Yes,
there will be one final solution chosen, but I don't think that should
preclude having multiple trees and approaches to view and hack on
during that decision making process. That way radical ideas can have a
place to be demonstrated to the community before the community adopting
them.
-peter
--
peter royal -> proyal@apache.org
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
RE: [VOTE] Creation of an "avalon" CVS repository for new Avalon5 codebase (Re: How to move forward?)
Posted by Carsten Ziegeler <cz...@s-und-n.de>.
Nicola Ken Barozzi wrote:
>
> I propose we have a new "avalon" CVS repository where to develop the new
> Avalon5 system. Things will be discussed and committed only when decided
> upon, and still eventually changed when again decided upon.
>
> This will make us do a clear cut with previous development methods, and
> clearly indicate that it's a new effort and that the old will be
> nevertheless maintained.
>
> +1 for a new "avalon" CVS repository
>
+0 - I'm not against it, but I'm not sure if it is worth creating
a new repository, why not making a directory inside the existing
repository with the same structure?
Creating a new repository has the effect that people will think
that it is something new (and incompatible) whether it is or not.
So, I'm +1 for a separate directory within our repository.
> Alternatively it can be called avalon5, avalonV, aValon, avalon-5,
> avalon-ng... the important thing is that it's there.
That's true.
Carsten
Carsten Ziegeler
Open Source Group, S&N AG
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
RE: [VOTE] Creation of an "avalon" CVS repository for new Avalon5 codebase (Re: How to move forward?)
Posted by Carsten Ziegeler <cz...@s-und-n.de>.
Nicola Ken Barozzi wrote:
>
> I propose we have a new "avalon" CVS repository where to develop the new
> Avalon5 system. Things will be discussed and committed only when decided
> upon, and still eventually changed when again decided upon.
>
> This will make us do a clear cut with previous development methods, and
> clearly indicate that it's a new effort and that the old will be
> nevertheless maintained.
>
> +1 for a new "avalon" CVS repository
>
+0 - I'm not against it, but I'm not sure if it is worth creating
a new repository, why not making a directory inside the existing
repository with the same structure?
Creating a new repository has the effect that people will think
that it is something new (and incompatible) whether it is or not.
So, I'm +1 for a separate directory within our repository.
> Alternatively it can be called avalon5, avalonV, aValon, avalon-5,
> avalon-ng... the important thing is that it's there.
That's true.
Carsten
Carsten Ziegeler
Open Source Group, S&N AG
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
[VOTE] Creation of an "avalon" CVS repository for new Avalon5 codebase
(Re: How to move forward?)
Posted by Nicola Ken Barozzi <ni...@apache.org>.
Noel J. Bergman wrote:
> I assume there will be multiple proposals going on
> in which case we can get things like;
> proposals/red
> proposals/blue
> proposals/green
> when one of them looks like it is a winner and has enough
> momentum split off a new CVS then.
>
>
> I've read Rules for Revolutionaries, too. But isn't the entire point of
> this exercise to move forward with ONE voice? I don't believe that
> institutionalizing factions is the best way to address that issue.
Agreed.
> The more I read the discussions here, the more it seems to me that the only
> thing that is going to get this community moving forward in unison is to
> have a single community container (scalable and profiled) under an Avalon
> CVS module, and preserve avalon-phoenix, avalon-excalibur/merlin, et al, for
> Avalon 4 container development while Avalon 5 is developed.
I propose we have a new "avalon" CVS repository where to develop the new
Avalon5 system. Things will be discussed and committed only when decided
upon, and still eventually changed when again decided upon.
This will make us do a clear cut with previous development methods, and
clearly indicate that it's a new effort and that the old will be
nevertheless maintained.
+1 for a new "avalon" CVS repository
Alternatively it can be called avalon5, avalonV, aValon, avalon-5,
avalon-ng... the important thing is that it's there.
--
Nicola Ken Barozzi nicolaken@apache.org
- verba volant, scripta manent -
(discussions get forgotten, just code remains)
---------------------------------------------------------------------
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
RE: How to move forward?
Posted by "Noel J. Bergman" <no...@devtech.com>.
> How can you vote on something unless you see it in action.
Do you not understand that perfection is not required for committing code?
What is important is a Community Consensus that it appears to be the right
thing to do at the time. Were one to take your statement literally, you
couldn't commit any code until it had been evaluated through a sandbox.
> Separate trees only become a problem when there is
> chest thumpers and code ownership galore.
There is an old Irish saying: begin as you intend to go on. I don't think
that it is a good practice to start with competing branches vying for
popularity. That is not a unified community.
> A little story [...]
Your story is quite similar to the one that you told me about Phoenix and
Merlin. Except, of course, that those two remain forked.
However, I do thank you for understanding why the "urn:" prefix is
important, since if a future need arose to support JNDI strings, e.g., to
integrate JINI components directly, the string passed could be "jndi:"
prefixed and the API for the lookup need not be changed.
> At no stage did we have any problems with the different proposals.
Selective examples. If this weren't a problem here, we wouldn't be having
this discussion.
--- Noel
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
RE: How to move forward?
Posted by "Noel J. Bergman" <no...@devtech.com>.
> How can you vote on something unless you see it in action.
Do you not understand that perfection is not required for committing code?
What is important is a Community Consensus that it appears to be the right
thing to do at the time. Were one to take your statement literally, you
couldn't commit any code until it had been evaluated through a sandbox.
> Separate trees only become a problem when there is
> chest thumpers and code ownership galore.
There is an old Irish saying: begin as you intend to go on. I don't think
that it is a good practice to start with competing branches vying for
popularity. That is not a unified community.
> A little story [...]
Your story is quite similar to the one that you told me about Phoenix and
Merlin. Except, of course, that those two remain forked.
However, I do thank you for understanding why the "urn:" prefix is
important, since if a future need arose to support JNDI strings, e.g., to
integrate JINI components directly, the string passed could be "jndi:"
prefixed and the API for the lookup need not be changed.
> At no stage did we have any problems with the different proposals.
Selective examples. If this weren't a problem here, we wouldn't be having
this discussion.
--- Noel
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
RE: How to move forward?
Posted by "Noel J. Bergman" <no...@devtech.com>.
> How can you vote on something unless you see it in action.
Do you not understand that perfection is not required for committing code?
What is important is a Community Consensus that it appears to be the right
thing to do at the time. Were one to take your statement literally, you
couldn't commit any code until it had been evaluated through a sandbox.
> Separate trees only become a problem when there is
> chest thumpers and code ownership galore.
There is an old Irish saying: begin as you intend to go on. I don't think
that it is a good practice to start with competing branches vying for
popularity. That is not a unified community.
> A little story [...]
Your story is quite similar to the one that you told me about Phoenix and
Merlin. Except, of course, that those two remain forked.
However, I do thank you for understanding why the "urn:" prefix is
important, since if a future need arose to support JNDI strings, e.g., to
integrate JINI components directly, the string passed could be "jndi:"
prefixed and the API for the lookup need not be changed.
> At no stage did we have any problems with the different proposals.
Selective examples. If this weren't a problem here, we wouldn't be having
this discussion.
--- Noel
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: How to move forward?
Posted by Peter Donald <pe...@realityforge.org>.
On Wed, 4 Dec 2002 20:08, Noel J. Bergman wrote:
> > I assume there will be multiple proposals going on
> > in which case we can get things like;
> > proposals/red
> > proposals/blue
> > proposals/green
> > when one of them looks like it is a winner and has enough
> > momentum split off a new CVS then.
>
> I've read Rules for Revolutionaries, too. But isn't the entire point of
> this exercise to move forward with ONE voice? I don't believe that
> institutionalizing factions is the best way to address that issue.
How can you vote on something uness you see it in action. Separate trees only
become a problem when there is chest thumpers and code ownership galore.
Given that the problem behaviour is unlikely to be attempted again - or at
least while there are upper managament about ;) then I don't think there will
be a problem.
A little story;
When I first got here I liked ComponentManagers simplicity and design. Berin
advocated JNDI to access services/context data. Then one week he finally
convinced me that JNDI was was better - funny thing was I had convinced him
that CM was better - so we "swapped" proposals. Then a few weeks later we
swapped again (ie I was +1 for CM he was +1 for JNDI). At no stage did we
have any problems with the different proposals.
--
Cheers,
Peter Donald
-----------------------------------------------------------------------
| I thought there was a knob on the TV to turn up the intelligence. |
| There's a knob called "brightness", but it doesn't work. |
-----------------------------------------------------------------------
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: How to move forward?
Posted by Peter Donald <pe...@realityforge.org>.
On Wed, 4 Dec 2002 20:08, Noel J. Bergman wrote:
> > I assume there will be multiple proposals going on
> > in which case we can get things like;
> > proposals/red
> > proposals/blue
> > proposals/green
> > when one of them looks like it is a winner and has enough
> > momentum split off a new CVS then.
>
> I've read Rules for Revolutionaries, too. But isn't the entire point of
> this exercise to move forward with ONE voice? I don't believe that
> institutionalizing factions is the best way to address that issue.
How can you vote on something uness you see it in action. Separate trees only
become a problem when there is chest thumpers and code ownership galore.
Given that the problem behaviour is unlikely to be attempted again - or at
least while there are upper managament about ;) then I don't think there will
be a problem.
A little story;
When I first got here I liked ComponentManagers simplicity and design. Berin
advocated JNDI to access services/context data. Then one week he finally
convinced me that JNDI was was better - funny thing was I had convinced him
that CM was better - so we "swapped" proposals. Then a few weeks later we
swapped again (ie I was +1 for CM he was +1 for JNDI). At no stage did we
have any problems with the different proposals.
--
Cheers,
Peter Donald
-----------------------------------------------------------------------
| I thought there was a knob on the TV to turn up the intelligence. |
| There's a knob called "brightness", but it doesn't work. |
-----------------------------------------------------------------------
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: How to move forward?
Posted by Peter Donald <pe...@realityforge.org>.
On Wed, 4 Dec 2002 20:08, Noel J. Bergman wrote:
> > I assume there will be multiple proposals going on
> > in which case we can get things like;
> > proposals/red
> > proposals/blue
> > proposals/green
> > when one of them looks like it is a winner and has enough
> > momentum split off a new CVS then.
>
> I've read Rules for Revolutionaries, too. But isn't the entire point of
> this exercise to move forward with ONE voice? I don't believe that
> institutionalizing factions is the best way to address that issue.
How can you vote on something uness you see it in action. Separate trees only
become a problem when there is chest thumpers and code ownership galore.
Given that the problem behaviour is unlikely to be attempted again - or at
least while there are upper managament about ;) then I don't think there will
be a problem.
A little story;
When I first got here I liked ComponentManagers simplicity and design. Berin
advocated JNDI to access services/context data. Then one week he finally
convinced me that JNDI was was better - funny thing was I had convinced him
that CM was better - so we "swapped" proposals. Then a few weeks later we
swapped again (ie I was +1 for CM he was +1 for JNDI). At no stage did we
have any problems with the different proposals.
--
Cheers,
Peter Donald
-----------------------------------------------------------------------
| I thought there was a knob on the TV to turn up the intelligence. |
| There's a knob called "brightness", but it doesn't work. |
-----------------------------------------------------------------------
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
[VOTE] Creation of an "avalon" CVS repository for new Avalon5 codebase
(Re: How to move forward?)
Posted by Nicola Ken Barozzi <ni...@apache.org>.
Noel J. Bergman wrote:
> I assume there will be multiple proposals going on
> in which case we can get things like;
> proposals/red
> proposals/blue
> proposals/green
> when one of them looks like it is a winner and has enough
> momentum split off a new CVS then.
>
>
> I've read Rules for Revolutionaries, too. But isn't the entire point of
> this exercise to move forward with ONE voice? I don't believe that
> institutionalizing factions is the best way to address that issue.
Agreed.
> The more I read the discussions here, the more it seems to me that the only
> thing that is going to get this community moving forward in unison is to
> have a single community container (scalable and profiled) under an Avalon
> CVS module, and preserve avalon-phoenix, avalon-excalibur/merlin, et al, for
> Avalon 4 container development while Avalon 5 is developed.
I propose we have a new "avalon" CVS repository where to develop the new
Avalon5 system. Things will be discussed and committed only when decided
upon, and still eventually changed when again decided upon.
This will make us do a clear cut with previous development methods, and
clearly indicate that it's a new effort and that the old will be
nevertheless maintained.
+1 for a new "avalon" CVS repository
Alternatively it can be called avalon5, avalonV, aValon, avalon-5,
avalon-ng... the important thing is that it's there.
--
Nicola Ken Barozzi nicolaken@apache.org
- verba volant, scripta manent -
(discussions get forgotten, just code remains)
---------------------------------------------------------------------
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
[VOTE] Creation of an "avalon" CVS repository for new Avalon5 codebase
(Re: How to move forward?)
Posted by Nicola Ken Barozzi <ni...@apache.org>.
Noel J. Bergman wrote:
> I assume there will be multiple proposals going on
> in which case we can get things like;
> proposals/red
> proposals/blue
> proposals/green
> when one of them looks like it is a winner and has enough
> momentum split off a new CVS then.
>
>
> I've read Rules for Revolutionaries, too. But isn't the entire point of
> this exercise to move forward with ONE voice? I don't believe that
> institutionalizing factions is the best way to address that issue.
Agreed.
> The more I read the discussions here, the more it seems to me that the only
> thing that is going to get this community moving forward in unison is to
> have a single community container (scalable and profiled) under an Avalon
> CVS module, and preserve avalon-phoenix, avalon-excalibur/merlin, et al, for
> Avalon 4 container development while Avalon 5 is developed.
I propose we have a new "avalon" CVS repository where to develop the new
Avalon5 system. Things will be discussed and committed only when decided
upon, and still eventually changed when again decided upon.
This will make us do a clear cut with previous development methods, and
clearly indicate that it's a new effort and that the old will be
nevertheless maintained.
+1 for a new "avalon" CVS repository
Alternatively it can be called avalon5, avalonV, aValon, avalon-5,
avalon-ng... the important thing is that it's there.
--
Nicola Ken Barozzi nicolaken@apache.org
- verba volant, scripta manent -
(discussions get forgotten, just code remains)
---------------------------------------------------------------------
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
RE: How to move forward?
Posted by "Noel J. Bergman" <no...@devtech.com>.
> I assume there will be multiple proposals going on
> in which case we can get things like;
> proposals/red
> proposals/blue
> proposals/green
> when one of them looks like it is a winner and has enough
> momentum split off a new CVS then.
I've read Rules for Revolutionaries, too. But isn't the entire point of
this exercise to move forward with ONE voice? I don't believe that
institutionalizing factions is the best way to address that issue.
The more I read the discussions here, the more it seems to me that the only
thing that is going to get this community moving forward in unison is to
have a single community container (scalable and profiled) under an Avalon
CVS module, and preserve avalon-phoenix, avalon-excalibur/merlin, et al, for
Avalon 4 container development while Avalon 5 is developed.
--- Noel
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
RE: How to move forward?
Posted by "Noel J. Bergman" <no...@devtech.com>.
> I assume there will be multiple proposals going on
> in which case we can get things like;
> proposals/red
> proposals/blue
> proposals/green
> when one of them looks like it is a winner and has enough
> momentum split off a new CVS then.
I've read Rules for Revolutionaries, too. But isn't the entire point of
this exercise to move forward with ONE voice? I don't believe that
institutionalizing factions is the best way to address that issue.
The more I read the discussions here, the more it seems to me that the only
thing that is going to get this community moving forward in unison is to
have a single community container (scalable and profiled) under an Avalon
CVS module, and preserve avalon-phoenix, avalon-excalibur/merlin, et al, for
Avalon 4 container development while Avalon 5 is developed.
--- Noel
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
RE: How to move forward?
Posted by "Noel J. Bergman" <no...@devtech.com>.
> I assume there will be multiple proposals going on
> in which case we can get things like;
> proposals/red
> proposals/blue
> proposals/green
> when one of them looks like it is a winner and has enough
> momentum split off a new CVS then.
I've read Rules for Revolutionaries, too. But isn't the entire point of
this exercise to move forward with ONE voice? I don't believe that
institutionalizing factions is the best way to address that issue.
The more I read the discussions here, the more it seems to me that the only
thing that is going to get this community moving forward in unison is to
have a single community container (scalable and profiled) under an Avalon
CVS module, and preserve avalon-phoenix, avalon-excalibur/merlin, et al, for
Avalon 4 container development while Avalon 5 is developed.
--- Noel
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: How to move forward?
Posted by Peter Donald <pe...@realityforge.org>.
On Wed, 4 Dec 2002 15:37, Berin Loritsch wrote:
> We need to make a branch in CVS to seperate new development from
> maintenance efforts on the old framework.
>
> The question is do we make the 4.1 code the branch and continue new
> efforts in the CVS HEAD or vice versa.
>
> Thoughts?
Develope in proposal/blah where blah is some random code name or color ie red.
I assume there will be multiple proposals going on in which case we can get
things like;
proposals/red
proposals/blue
proposals/green
when one of them looks like it is a winner and has enough momentum split off a
new CVS then.
--
Cheers,
Peter Donald
'Most men would rather die than think. Many do.'
Bertrand Russell
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: How to move forward?
Posted by Peter Donald <pe...@realityforge.org>.
On Wed, 4 Dec 2002 15:37, Berin Loritsch wrote:
> We need to make a branch in CVS to seperate new development from
> maintenance efforts on the old framework.
>
> The question is do we make the 4.1 code the branch and continue new
> efforts in the CVS HEAD or vice versa.
>
> Thoughts?
Develope in proposal/blah where blah is some random code name or color ie red.
I assume there will be multiple proposals going on in which case we can get
things like;
proposals/red
proposals/blue
proposals/green
when one of them looks like it is a winner and has enough momentum split off a
new CVS then.
--
Cheers,
Peter Donald
'Most men would rather die than think. Many do.'
Bertrand Russell
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: How to move forward?
Posted by Peter Donald <pe...@realityforge.org>.
On Wed, 4 Dec 2002 15:37, Berin Loritsch wrote:
> We need to make a branch in CVS to seperate new development from
> maintenance efforts on the old framework.
>
> The question is do we make the 4.1 code the branch and continue new
> efforts in the CVS HEAD or vice versa.
>
> Thoughts?
Develope in proposal/blah where blah is some random code name or color ie red.
I assume there will be multiple proposals going on in which case we can get
things like;
proposals/red
proposals/blue
proposals/green
when one of them looks like it is a winner and has enough momentum split off a
new CVS then.
--
Cheers,
Peter Donald
'Most men would rather die than think. Many do.'
Bertrand Russell
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: How NOT to move forward
Posted by Leo Simons <le...@apache.org>.
On Wed, 2002-12-04 at 22:52, Noel J. Bergman wrote:
<snip/>
hear hear. Totally agree. I'm posting me-toos against netiquette because
I think metoos are good in a climate of -1s :D
cheers,
- Leo
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: How NOT to move forward
Posted by Peter Donald <pe...@realityforge.org>.
On Thu, 5 Dec 2002 08:52, Noel J. Bergman wrote:
> I'll conclude with a thought regarding technical vetoes. Consider this:
> why must a justification must be given for a technical veto? Do you
> suppose that the purpose is simply to provide an excuse for the veto? I
> submit that it is about providing a basis for reaching a new consensus.
> Consensus isn't about one person being able to act as a roadblock. It is
> about focusing attention on critical issues on the belief that the
> community consensus will be the best solution available at that time.
Thats on the money .. or at least thats how it should be ;)
--
Cheers,
Peter Donald
*--------------------------------*
| Every rule has an exception, |
| except the rule of exceptions. |
*--------------------------------*
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: How NOT to move forward
Posted by Paul Hammant <pa...@yahoo.com>.
> > It is the nature of
> > this ambitious project to deliver large revolutionary as opposed to
> > slowly evolved projects (when considering cntainers).
>
> Disagree. The wise nature of an ambitious project is to save energy for
> the battles with others, not between themselves.
Ahh, I'd agree on the subject of battles. My statement concerned a prior time when all container
work was encouraged, embraced, enthused on.
-ph
__________________________________________________
Do You Yahoo!?
Everything you'll ever need on one web page
from News and Sport to Email and Music Charts
http://uk.my.yahoo.com
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: How NOT to move forward
Posted by Stefano Mazzocchi <st...@apache.org>.
Paul Hammant wrote:
> It is the nature of
> this ambitious project to deliver large revolutionary as opposed to
> slowly evolved projects (when considering cntainers).
Disagree. The wise nature of an ambitious project is to save energy for
the battles with others, not between themselves.
I did my ego-based revolution back in 1998 on JServ. I've learned that
my ego is my worst enemy. Funny how your ego drives you in a path where
you waste a bunch of energy and at the end you find out how silly and
childish the whole thing was.
But I also learned that there is no way these lessons are learned by
others simply because you tell them. That's life.
--
Stefano Mazzocchi <st...@apache.org>
--------------------------------------------------------------------
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
RE: How NOT to move forward
Posted by "Noel J. Bergman" <no...@devtech.com>.
> I'm actually *really* hoping for *evolution* for James3.
Let's talk about this on james-dev after the [ANN] goes out for v2.1. :-)
But don't fret that anyone is even contemplating tossing out the v2 code and
starting over! Most will be evolutionary, but I personally expect some
things to change that won't be compatible with certain areas of the existing
code base.
Getting back to Avalon 5, most of the Frameworks would probably survive
unchanged. And I suspect that after architecting and designing the
scalable, profilable container, that parts of the profiles would be pulled
from the existing code base. There really is good code here, which is why
we're all using it (and worrying over the health of the supporting
community).
In either case, you look at requirements, review the architecture, design,
and code, and go from there.
--- Noel
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: How NOT to move forward
Posted by Darrell DeBoer <da...@apache.org>.
On Fri, 6 Dec 2002 07:05, Noel J. Bergman wrote:
> I expect revolution in James v3 (by definition; else it would still be
> James v2).
I'm actually *really* hoping for *evolution* for James3. In my experience,
gradually evolving and refactoring a *working* product usually works out
better than trying to clean-slate it. I think this is as much due to social
and community factors as it is due to technical ones. I would always try the
evolutionary approach first, and only go for revolution as a last resort.
Then again, I'm only one of the voices. (and this is way off-topic for this
list).
--
cheers,
Darrell DeBoer
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
RE: How NOT to move forward
Posted by "Noel J. Bergman" <no...@devtech.com>.
Paul,
> OK, We have one primary art - Avalon-Framework interfaces. Despite
> chatter about Avalon5 they are remarkably stable.
Yes, I think so, too. The issues I see at the moment are related to
Context, Component/Service, and various issues that are meta-data related.
All of which can be resolved in due course.
The dialogue between Adam, Darrell, and Gary is interesting. You have three
consumers of Avalon each expressing similar issues with fundamental
questions about the role of Context. But I won't digress further ...
> The vision of a container is something we all have
> in our heads clearly.
Well, the vision to have a container is clear, but I don't agree that the
details are at all clear as a shared vision.
> It is easy for us to imagine a new container.
> New containers are often revolutions
I expect revolution in James v3 (by definition; else it would still be James
v2). That doesn't mean that we are going to split the community. The whole
community will support the revolution. Apply that to Avalon: whatever form
Avalon 5 takes technically, everyone needs to get behind it as a single
Community, and then shape that form collective.
> Just because we have two containers and a number of smaller
> beany projects that suport them, it does not mean that we
> are dysfunctional.
You'll notice that my original quotes weren't about the existing code. It
was about how people expect the process to work (or not), within the
community.
--- Noel
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: How NOT to move forward
Posted by Paul Hammant <Pa...@yahoo.com>.
Noel,
An interesting read. So is Nicola's cut/paste job from Ken Coar. So is
Steffano's on Tomcat/Catalina.
OK, We have one primary art - Avalon-Framework interfaces. Despite
chatter about Avalon5 they are remarkably stable. The vision of a
container is something we all have in our heads clearly. It is easy for
us to imagine a new container. New containers are often revolutions,
and lo and behold we often start coding them in earnest. We have a
excellent newer container called Merlin that was formed from one such
revolution. We have an excellent older container called Phoenix that
itself was previously formed from one such revolution. Just because we
have two containers and a number of smaller beany projects that suport
them, it does not mean that we are dysfunctional. It is the nature of
this ambitious project to deliver large revolutionary as opposed to
slowly evolved projects (when considering cntainers).
- Paul
>Various quotes (deliberately without attribution):
>
>
>
>>I think it makes sense to do the first prototyping in avalon-sandbox,
>>and everytime we have consensus on a piece, that can go someplace new,
>>whether it's a new repository or a branch in the existing one.
>>
>>
>
>
>
>>The container needs to be started in avalon-sandbox.
>>
>>
>
>
>
>>It is pretty cool to have a plethora of codebases and snippets
>>
>>
>
>
>
>>I do like [the] idea of having multiple proposal directories. Yes,
>>there will be one final solution chosen, but I don't think that
>>should preclude having multiple trees and approaches to view and
>>hack on during that decision making process. That way radical
>>ideas can have a place to be demonstrated to the community before
>>the community adopting them.
>>
>>
>
>Does no one realize that the Avalon project has institutionalized a
>psychology that says fork first, consensus later? Avalon appears to be so
>dysfunctional as a community that people first try to create a proof that an
>approach is the correct one because otherwise the community can't agree.
>The presumption is that there will be multiple ideas and that consensus
>can't be achieved without competition. At first the code is "just a
>proposal", but when consensus is not forthcoming, the project (hard to call
>it a community at that point) just ends up with disparate pieces.
>
>Partially, what appears to be happening, even now, is that people (perhaps
>subconsciously) are jockeying to preserve their ability to do what they want
>without having to reach a consensus. They'll only reach one when/if they've
>finished competing.
>
>But I don't believe that this is about ego and competing. A related, and
>very significant, issue appears to be a concern about being shut out of the
>process, and having one faction eliminate another. There is a major lack of
>trust within this community. And that is a very unhealthy psychology.
>
>Furthermore, because the community does not agree beforehand on what
>approach to take, it cannot effectively marshal community resources.
>Instead of having people working on different facets of a common vision, it
>wastes its resources developing competing visions of the same facet. And it
>alienates potential contributors (and consumers).
>
>Constantly developing multiple implementations, and then voting on which one
>is best is not how a community project is supposed to work. At least not by
>my definition of community, nor by the one that I believe the ASF is trying
>to foster. Someone please correct me if I am wrong.
>
>So ... having just let loose with this criticism, where are the constructive
>suggestions that I ought to offer to address it? Well, let's all
>acknowledge that on the positive side, despite the current community issues,
>Avalon has delivered important, useful, technology, and we all want it to
>continue to do so. [Wouldn't be here otherwise!] I recognize that the
>current psychology didn't appear overnight, and is unlikely to change via an
>epiphany. Even the most reasonable people here are showing the symptoms.
>But people really ought to reflect on what is going on here, and why they
>feel the way that they do. And THEN, what they can do to change it in favor
>of community building.
>
>So what to do? The Avalon Community is part of a larger Community. I
>submit that in the face of these internal issues, the solution is to trust
>the ASF Community Process -- as it is promoted. No more jockeying for
>position or protecting turf. Accept the philosophy that the community is
>more important than the code. I understand that you cannot move forward in
>an climate of mistrust, either social or technical. So if you can't trust
>your fellow community members, trust the larger community and the process --
>consider them a safety net. Hopefully the former can be rebuilt from the
>latter.
>
>I'll conclude with a thought regarding technical vetoes. Consider this: why
>must a justification must be given for a technical veto? Do you suppose
>that the purpose is simply to provide an excuse for the veto? I submit that
>it is about providing a basis for reaching a new consensus. Consensus isn't
>about one person being able to act as a roadblock. It is about focusing
>attention on critical issues on the belief that the community consensus will
>be the best solution available at that time.
>
> --- Noel
>
>
>--
>To unsubscribe, e-mail: <ma...@jakarta.apache.org>
>For additional commands, e-mail: <ma...@jakarta.apache.org>
>
>
>
>
>
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
RE: How NOT to move forward
Posted by Leo Sutic <le...@inspireinfrastructure.com>.
Noel,
well written. I think Davit Weitzman was saying something
similar in regards to interests vs. positions in his
posting.
/LS
> From: Noel J. Bergman [mailto:noel@devtech.com]
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
How NOT to move forward
Posted by "Noel J. Bergman" <no...@devtech.com>.
Various quotes (deliberately without attribution):
> I think it makes sense to do the first prototyping in avalon-sandbox,
> and everytime we have consensus on a piece, that can go someplace new,
> whether it's a new repository or a branch in the existing one.
> The container needs to be started in avalon-sandbox.
> It is pretty cool to have a plethora of codebases and snippets
> I do like [the] idea of having multiple proposal directories. Yes,
> there will be one final solution chosen, but I don't think that
> should preclude having multiple trees and approaches to view and
> hack on during that decision making process. That way radical
> ideas can have a place to be demonstrated to the community before
> the community adopting them.
Does no one realize that the Avalon project has institutionalized a
psychology that says fork first, consensus later? Avalon appears to be so
dysfunctional as a community that people first try to create a proof that an
approach is the correct one because otherwise the community can't agree.
The presumption is that there will be multiple ideas and that consensus
can't be achieved without competition. At first the code is "just a
proposal", but when consensus is not forthcoming, the project (hard to call
it a community at that point) just ends up with disparate pieces.
Partially, what appears to be happening, even now, is that people (perhaps
subconsciously) are jockeying to preserve their ability to do what they want
without having to reach a consensus. They'll only reach one when/if they've
finished competing.
But I don't believe that this is about ego and competing. A related, and
very significant, issue appears to be a concern about being shut out of the
process, and having one faction eliminate another. There is a major lack of
trust within this community. And that is a very unhealthy psychology.
Furthermore, because the community does not agree beforehand on what
approach to take, it cannot effectively marshal community resources.
Instead of having people working on different facets of a common vision, it
wastes its resources developing competing visions of the same facet. And it
alienates potential contributors (and consumers).
Constantly developing multiple implementations, and then voting on which one
is best is not how a community project is supposed to work. At least not by
my definition of community, nor by the one that I believe the ASF is trying
to foster. Someone please correct me if I am wrong.
So ... having just let loose with this criticism, where are the constructive
suggestions that I ought to offer to address it? Well, let's all
acknowledge that on the positive side, despite the current community issues,
Avalon has delivered important, useful, technology, and we all want it to
continue to do so. [Wouldn't be here otherwise!] I recognize that the
current psychology didn't appear overnight, and is unlikely to change via an
epiphany. Even the most reasonable people here are showing the symptoms.
But people really ought to reflect on what is going on here, and why they
feel the way that they do. And THEN, what they can do to change it in favor
of community building.
So what to do? The Avalon Community is part of a larger Community. I
submit that in the face of these internal issues, the solution is to trust
the ASF Community Process -- as it is promoted. No more jockeying for
position or protecting turf. Accept the philosophy that the community is
more important than the code. I understand that you cannot move forward in
an climate of mistrust, either social or technical. So if you can't trust
your fellow community members, trust the larger community and the process --
consider them a safety net. Hopefully the former can be rebuilt from the
latter.
I'll conclude with a thought regarding technical vetoes. Consider this: why
must a justification must be given for a technical veto? Do you suppose
that the purpose is simply to provide an excuse for the veto? I submit that
it is about providing a basis for reaching a new consensus. Consensus isn't
about one person being able to act as a roadblock. It is about focusing
attention on critical issues on the belief that the community consensus will
be the best solution available at that time.
--- Noel
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
RE: How to move forward?
Posted by Berin Loritsch <bl...@citi-us.com>.
> From: Leo Simons [mailto:leosimons@apache.org]
>
> Call me a donut but I find working with branches very puzzling (notice
> my lack of updates to the forrest docs in framework cvs). I am sure I
> will make mistakes if we do lots of stuff on branches.
Ok donut ;P,
Seriously though that is why I suggested working either as 4.1 (maintenance)
in the HEAD branch or the new version 5.0. I would lean towards the
current stuff being in the branch and the new stuff in HEAD.
> I think it makes sense to do the first prototyping in avalon-sandbox,
> and everytime we have consensus on a piece, that can go someplace new,
> whether it's a new repository or a branch in the existing one.
For the container, yes. The container needs to be started in
avalon-sandbox.
For framework, I want to work on one repository. I want to clean out
all the deprecated stuff so that talks can begin from the current status
and clean plate.
> I think we need to slowly move to living without the "jakarta" prefix
> regardless :D
I agree. BTW, we need to archive the contents from "Testlet" CVS, and
then remove the CVS repository. The archive can be placed in a new
CVS just in case someone wants to revive it.
> I don't think this stuff should be played according to "rules for
> revolutionaries". We'll hurt the community. It is pretty cool
> to have a
> plethora of codebases and snippets in (sandbox) CVS (as long as it is
> not in the way of users and it is a common rather than a personal
> playground it's all okay with me), but we shouldn't apply the whole
> majority-rules idea to it.
I don't like having a bunch of separate directories. Let's focus
one step at a time on one Avalon, one community vision.
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
RE: How to move forward?
Posted by Berin Loritsch <bl...@citi-us.com>.
> From: Leo Simons [mailto:leosimons@apache.org]
>
> Call me a donut but I find working with branches very puzzling (notice
> my lack of updates to the forrest docs in framework cvs). I am sure I
> will make mistakes if we do lots of stuff on branches.
Ok donut ;P,
Seriously though that is why I suggested working either as 4.1 (maintenance)
in the HEAD branch or the new version 5.0. I would lean towards the
current stuff being in the branch and the new stuff in HEAD.
> I think it makes sense to do the first prototyping in avalon-sandbox,
> and everytime we have consensus on a piece, that can go someplace new,
> whether it's a new repository or a branch in the existing one.
For the container, yes. The container needs to be started in
avalon-sandbox.
For framework, I want to work on one repository. I want to clean out
all the deprecated stuff so that talks can begin from the current status
and clean plate.
> I think we need to slowly move to living without the "jakarta" prefix
> regardless :D
I agree. BTW, we need to archive the contents from "Testlet" CVS, and
then remove the CVS repository. The archive can be placed in a new
CVS just in case someone wants to revive it.
> I don't think this stuff should be played according to "rules for
> revolutionaries". We'll hurt the community. It is pretty cool
> to have a
> plethora of codebases and snippets in (sandbox) CVS (as long as it is
> not in the way of users and it is a common rather than a personal
> playground it's all okay with me), but we shouldn't apply the whole
> majority-rules idea to it.
I don't like having a bunch of separate directories. Let's focus
one step at a time on one Avalon, one community vision.
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
RE: How to move forward?
Posted by Berin Loritsch <bl...@citi-us.com>.
> From: Leo Simons [mailto:leosimons@apache.org]
>
> Call me a donut but I find working with branches very puzzling (notice
> my lack of updates to the forrest docs in framework cvs). I am sure I
> will make mistakes if we do lots of stuff on branches.
Ok donut ;P,
Seriously though that is why I suggested working either as 4.1 (maintenance)
in the HEAD branch or the new version 5.0. I would lean towards the
current stuff being in the branch and the new stuff in HEAD.
> I think it makes sense to do the first prototyping in avalon-sandbox,
> and everytime we have consensus on a piece, that can go someplace new,
> whether it's a new repository or a branch in the existing one.
For the container, yes. The container needs to be started in
avalon-sandbox.
For framework, I want to work on one repository. I want to clean out
all the deprecated stuff so that talks can begin from the current status
and clean plate.
> I think we need to slowly move to living without the "jakarta" prefix
> regardless :D
I agree. BTW, we need to archive the contents from "Testlet" CVS, and
then remove the CVS repository. The archive can be placed in a new
CVS just in case someone wants to revive it.
> I don't think this stuff should be played according to "rules for
> revolutionaries". We'll hurt the community. It is pretty cool
> to have a
> plethora of codebases and snippets in (sandbox) CVS (as long as it is
> not in the way of users and it is a common rather than a personal
> playground it's all okay with me), but we shouldn't apply the whole
> majority-rules idea to it.
I don't like having a bunch of separate directories. Let's focus
one step at a time on one Avalon, one community vision.
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: How to move forward?
Posted by Leo Simons <le...@apache.org>.
Call me a donut but I find working with branches very puzzling (notice
my lack of updates to the forrest docs in framework cvs). I am sure I
will make mistakes if we do lots of stuff on branches.
I think it makes sense to do the first prototyping in avalon-sandbox,
and everytime we have consensus on a piece, that can go someplace new,
whether it's a new repository or a branch in the existing one.
I think we need to slowly move to living without the "jakarta" prefix
regardless :D
I don't think this stuff should be played according to "rules for
revolutionaries". We'll hurt the community. It is pretty cool to have a
plethora of codebases and snippets in (sandbox) CVS (as long as it is
not in the way of users and it is a common rather than a personal
playground it's all okay with me), but we shouldn't apply the whole
majority-rules idea to it.
cheers,
- Leo
On Wed, 2002-12-04 at 05:37, Berin Loritsch wrote:
> We need to make a branch in CVS to seperate new development from
> maintenance efforts on the old framework.
>
> The question is do we make the 4.1 code the branch and continue new
> efforts in the CVS HEAD or vice versa.
>
> Thoughts?
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: How to move forward?
Posted by Leo Simons <le...@apache.org>.
Call me a donut but I find working with branches very puzzling (notice
my lack of updates to the forrest docs in framework cvs). I am sure I
will make mistakes if we do lots of stuff on branches.
I think it makes sense to do the first prototyping in avalon-sandbox,
and everytime we have consensus on a piece, that can go someplace new,
whether it's a new repository or a branch in the existing one.
I think we need to slowly move to living without the "jakarta" prefix
regardless :D
I don't think this stuff should be played according to "rules for
revolutionaries". We'll hurt the community. It is pretty cool to have a
plethora of codebases and snippets in (sandbox) CVS (as long as it is
not in the way of users and it is a common rather than a personal
playground it's all okay with me), but we shouldn't apply the whole
majority-rules idea to it.
cheers,
- Leo
On Wed, 2002-12-04 at 05:37, Berin Loritsch wrote:
> We need to make a branch in CVS to seperate new development from
> maintenance efforts on the old framework.
>
> The question is do we make the 4.1 code the branch and continue new
> efforts in the CVS HEAD or vice versa.
>
> Thoughts?
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: How to move forward?
Posted by Leo Simons <le...@apache.org>.
Call me a donut but I find working with branches very puzzling (notice
my lack of updates to the forrest docs in framework cvs). I am sure I
will make mistakes if we do lots of stuff on branches.
I think it makes sense to do the first prototyping in avalon-sandbox,
and everytime we have consensus on a piece, that can go someplace new,
whether it's a new repository or a branch in the existing one.
I think we need to slowly move to living without the "jakarta" prefix
regardless :D
I don't think this stuff should be played according to "rules for
revolutionaries". We'll hurt the community. It is pretty cool to have a
plethora of codebases and snippets in (sandbox) CVS (as long as it is
not in the way of users and it is a common rather than a personal
playground it's all okay with me), but we shouldn't apply the whole
majority-rules idea to it.
cheers,
- Leo
On Wed, 2002-12-04 at 05:37, Berin Loritsch wrote:
> We need to make a branch in CVS to seperate new development from
> maintenance efforts on the old framework.
>
> The question is do we make the 4.1 code the branch and continue new
> efforts in the CVS HEAD or vice versa.
>
> Thoughts?
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>