You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@avalon.apache.org by "Noel J. Bergman" <no...@devtech.com> on 2002/12/04 22:52:26 UTC
How NOT to move forward
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 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>