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/11/19 22:42:51 UTC
A Little Consideration and Decorum, Please.
Gentlemen, the purpose of this note is to address some of the behavior and
actions being taken by members of the Avalon projects. Not the least
because I am a Committer on a project that uses Avalon (NB: I am not
speaking in an official project level capacity). Plus, I just came back
from a week long conference where I promoted Avalon (along with other
Jakarta technologies) to 100s of other developers for them to consider on
their projects.
Paul Hammant will rightly want to remind me that Avalon is not one thing.
Correct. It is a set of things, and we use many of them:
- Avalon Frameworks
- Avalon Cornerstone
- Avalon Excalibur
- Avalon Phoenix
- some services
And we are perfectly happy to be hosted in alternative containers such as
Merlin, although we are not actively performing that work.
Gentlemen, Avalon is no one's private fiefdom. It is an Apache project and,
aside from the ASF, your real customers are US, the projects using this
code. We may not participate here very often (I occasionally browse the
mailing list archives), but we exist and we count.
Gentlemen, there are real projects built on top of this code base. Avalon
is, and should be able to continue to be, an important foundation for
server-side software. All that you are doing is diminishing its value and
scaring people into removing it, or bypassing it.
I am more than half tempted to suggest that any Committer from any project
with a reliance upon this codebase ought to be involved in your voting
process. I joined this list because I've been asked repeatedly to please
join the mailing list to see the "war" that was brewing here, because of our
dependencies upon the code. I was informed that the issue had escalated
beyond your usual bickering.
You will notice that I am not singling out anyone to criticize. I am not
going to get into the personalities (and, yes, I know who you are, and I've
been browsing the archives since the Spring). There is more than enough
childish behavior to go around, and clearly not enough adult supervision.
Frankly, I have seen few names who haven't posted messages that they
shouldn't be ashamed of what they've said in public. Conversely, I have not
see anyone who was entirely without a valid point from time to time.
Migrating Frameworks and Excalibur to Commons, and making Merlin and Phoenix
their own TLPs do not appear to cure the problem. Merlin and Phoenix, as
sub-projects, can already go their own ways within the proscribed
requirement that, as Paul Hammant would want me to add, Avalon-Frameworks is
the level at which compatibility between containers is guaranteed. All that
this refactoring of projects appears to do is reshuffle the voting deck.
I have a different proposal of sorts. As I see it, the Apache Way mandates
consensus. A single -1 on a code change from any Committer is a binding
veto. Applying this to Avalon means that any Committer can veto changes on
Frameworks and other common code.
Again, having read through a lot of the mailing list archives over the past
6+ months, I suggest that Committers from projects using Avalon Frameworks
projects ought to have say in how CORE INTERFACES are changed. We are the
ones USING them. But, since client code should not need to be container
dependent (if we choose to take advantages of services specific to a given
container, that's our mistake), I don't see any point in clients having a
vote on the implementation sub-projects.
Furthermore, I do not think that there is a valid point to an implementer on
one sub-project blocking work on another upon which they don't depend.
Containers, for example, are peers. Their members should not be interfering
with each other.
If this means that there needs to be cleaner lines drawn regarding
sub-projects such as Cornerstone and Excalibur, then draw them and be done
with it. If they are available for ANY containers to use, then they are
equally shared. If they are part of a given container's domain, make it
clear and let the other containers clone them now.
Gentlemen, I urge you to all stop for a moment and consider the impact of
your words and your behavior, which you are carrying out in a public venue.
And I remind you whom your clients are. We may not have been paying enough
attention before now, but this behavior requires our attention.
--- Noel
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: A Little Consideration and Decorum, Please.
Posted by Stephen McConnell <mc...@apache.org>.
Nicola Ken Barozzi wrote:
>
> Dear Noel,
> thank you heartily for this deeply inspired mail.
>
>
> What you outline should now guide us in the definition of our project
> guidelines, and we must focus on our users.
>
> I second your suggestion to stop for a moment and consider the impact of
> our words and our behavior.
>
> -oOo-
+1
--
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: A Little Consideration and Decorum, Please.
Posted by Nicola Ken Barozzi <ni...@apache.org>.
Dear Noel,
thank you heartily for this deeply inspired mail.
What you outline should now guide us in the definition of our project
guidelines, and we must focus on our users.
I second your suggestion to stop for a moment and consider the impact of
our words and our behavior.
-oOo-
Yesterday, the board has effectively created the Avalon PMC.
I am announcing it in this mail in minor tone and not with a new mail
subject because it's just a first step.
Avalon is an Apache community made of people, that build great software.
Let's all work to make this at our best.
-oOo-
Noel J. Bergman wrote:
> Gentlemen, the purpose of this note is to address some of the behavior and
> actions being taken by members of the Avalon projects. Not the least
> because I am a Committer on a project that uses Avalon (NB: I am not
> speaking in an official project level capacity). Plus, I just came back
> from a week long conference where I promoted Avalon (along with other
> Jakarta technologies) to 100s of other developers for them to consider on
> their projects.
>
> Paul Hammant will rightly want to remind me that Avalon is not one thing.
> Correct. It is a set of things, and we use many of them:
>
> - Avalon Frameworks
> - Avalon Cornerstone
> - Avalon Excalibur
> - Avalon Phoenix
> - some services
>
> And we are perfectly happy to be hosted in alternative containers such as
> Merlin, although we are not actively performing that work.
>
> Gentlemen, Avalon is no one's private fiefdom. It is an Apache project and,
> aside from the ASF, your real customers are US, the projects using this
> code. We may not participate here very often (I occasionally browse the
> mailing list archives), but we exist and we count.
>
> Gentlemen, there are real projects built on top of this code base. Avalon
> is, and should be able to continue to be, an important foundation for
> server-side software. All that you are doing is diminishing its value and
> scaring people into removing it, or bypassing it.
>
> I am more than half tempted to suggest that any Committer from any project
> with a reliance upon this codebase ought to be involved in your voting
> process. I joined this list because I've been asked repeatedly to please
> join the mailing list to see the "war" that was brewing here, because of our
> dependencies upon the code. I was informed that the issue had escalated
> beyond your usual bickering.
>
> You will notice that I am not singling out anyone to criticize. I am not
> going to get into the personalities (and, yes, I know who you are, and I've
> been browsing the archives since the Spring). There is more than enough
> childish behavior to go around, and clearly not enough adult supervision.
> Frankly, I have seen few names who haven't posted messages that they
> shouldn't be ashamed of what they've said in public. Conversely, I have not
> see anyone who was entirely without a valid point from time to time.
>
> Migrating Frameworks and Excalibur to Commons, and making Merlin and Phoenix
> their own TLPs do not appear to cure the problem. Merlin and Phoenix, as
> sub-projects, can already go their own ways within the proscribed
> requirement that, as Paul Hammant would want me to add, Avalon-Frameworks is
> the level at which compatibility between containers is guaranteed. All that
> this refactoring of projects appears to do is reshuffle the voting deck.
>
> I have a different proposal of sorts. As I see it, the Apache Way mandates
> consensus. A single -1 on a code change from any Committer is a binding
> veto. Applying this to Avalon means that any Committer can veto changes on
> Frameworks and other common code.
>
> Again, having read through a lot of the mailing list archives over the past
> 6+ months, I suggest that Committers from projects using Avalon Frameworks
> projects ought to have say in how CORE INTERFACES are changed. We are the
> ones USING them. But, since client code should not need to be container
> dependent (if we choose to take advantages of services specific to a given
> container, that's our mistake), I don't see any point in clients having a
> vote on the implementation sub-projects.
>
> Furthermore, I do not think that there is a valid point to an implementer on
> one sub-project blocking work on another upon which they don't depend.
> Containers, for example, are peers. Their members should not be interfering
> with each other.
>
> If this means that there needs to be cleaner lines drawn regarding
> sub-projects such as Cornerstone and Excalibur, then draw them and be done
> with it. If they are available for ANY containers to use, then they are
> equally shared. If they are part of a given container's domain, make it
> clear and let the other containers clone them now.
>
> Gentlemen, I urge you to all stop for a moment and consider the impact of
> your words and your behavior, which you are carrying out in a public venue.
> And I remind you whom your clients are. We may not have been paying enough
> attention before now, but this behavior requires our attention.
>
> --- Noel
--
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: A Little Consideration and Decorum, Please.
Posted by Stephen McConnell <mc...@apache.org>.
First off, thank you Noel for you message - a checkpoint well heeded.
Pete - thank you for kicking of direction from within that context.
See notes in-line:
Peter M. Goldstein wrote:
>All,
>
>I'd like to second the sentiment and message conveyed by Noel. As yet
>another committer on an Avalon-dependent project and a long-time lurker
>on the Avalon developers' list, I've been extremely concerned by the
>recent threads on the list. While conflict is often constructive, I
>don't believe the recent threads serve the general good.
>
>There's one point that Noel made that I'd like to expound upon further.
>
>
>
>>If this means that there needs to be cleaner lines drawn regarding
>>sub-projects such as Cornerstone and Excalibur, then draw them and
>>be done with it. If they are available for ANY containers to use,
>>then they are equally shared. If they are part of a given
>>container's domain, make it clear and let the other containers
>>clone them now.
>>
>>
>
>As I see it this, as much as the personality conflicts, is the root
>problem.
>
Cornerstone has and remains an obsticle - cleaning this one up would go
a long way to eliminating an point of technical friction. A simple vote
on Cornerstone positioning relative to Avalon and its sub-projects would
highly benefitial. Excalibur on the other-hand, is generally speaking,
well broken out in terms of functional units, but drawing the lines will
require a more engagement/attention that the Cornerstone issue.
>
>We have a couple (perhaps more than a couple) of different visions of
>what features and behaviors an Avalon container should provide. That's
>good. Contrasting visions, when brought to the larger community, can
>help drive innovation and product development. No one has a monopoly on
>good ideas (and, as is less often stated, no one is immune from at least
>the occasional bad idea).
>
>We have strong personalities driving those visions. That's also good -
>strong advocates are important. Otherwise ideas die on the vine.
>
>What we don't have is a clear exposition of those visions, their points
>of intersection, and their points of divergence. Maybe other people on
>this list feel differently, but I believe that a lot of this could be
>resolved by a frank and open technical discussion under Apache
>guidelines. I'm still not clear what specific goals the members of each
>group are trying to achieve. It would also be an opportunity for those
>of us who are Avalon consumers to bring to the developers' attention
>some of the things that we find most confusing/inadequate (i.e.
>identity/typing of objects provided in the context).
>
>The goal of this discussion would be to precisely delineate what falls
>into the framework and what does not. The framework constitutes the
>common services available in and behaviors provided by all Avalon
>containers. Note that the Framework is not only the set of interfaces,
>but is also a clear statement of the container-component contracts that
>those interfaces represent.
>
>
+1
>Anything outside of the framework scope may or may not be provided by a
>container. "Extras" provided by a particular container may later make
>it in (perhaps in altered form) to a later rev of the framework. Anyone
>who writes code that depends on a container-specific feature is
>committing themselves to that container. This is exactly how the world
>of commercial app servers works.
>
+1
Rephrasing this in a schematic:
|----------------------------------|
| Avalon Framework Client API | <-- standard (current framework)
|----------------------------------|
| Avalon Framework Container API | <-- standard (future)
|----------------------------------|
| Xxxxx Container Propriatory API | <-- custom container added value
|----------------------------------| (Phoniex, Merlin, ...)
>As far as the impact on the codebase, the end result of such a
>discussion would be a set of framework classes and Apache/Jakarta
>commons classes which are common, and several sets of container specific
>classes in different, non-conflicting container specific packages. In
>the end, render unto Framework what is Framework's, Commons what is
>Commons, Phoenix what is Phoenix's, and Merlin what is Merlin's.
>
>Yes, such a discussion would be a distraction from writing code. And
>some tend to view discussions like this as a waste of time. But Avalon
>has grown into a diverse and active community, with a number of
>"customers". That means it needs to devote real time to discussion of
>these high-level issues. Otherwise, IMHO, more lovely and unproductive
>email battles are inevitable.
>
I would really like to see something like this go into a document(s),
with input from users with different priorities (a.k.a. viewpoints and
usage scenarios). So take my +1 as a "I agree and I'm willing to put
effort into it".
>
>On a not quite related note, another reason for this discussion is that
>it might serve as the basis of new Avalon marketing documentation. This
>marketing effort would serve to solidify current users and attract new
>ones. This would help spread the Avalon vision as well as making Avalon
>evangelizing easier for those of us on products where there is a "ditch
>Avalon" movement. Just a thought.
>
+100
Also willing and able to contribute to this.
Cheers, Steve.
>
>--Peter
>
>
>
>
>
>
>--
>To unsubscribe, e-mail: <ma...@jakarta.apache.org>
>For additional commands, e-mail: <ma...@jakarta.apache.org>
>
>
>
>
>
--
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: A Little Consideration and Decorum, Please.
Posted by "Peter M. Goldstein" <pe...@yahoo.com>.
All,
I'd like to second the sentiment and message conveyed by Noel. As yet
another committer on an Avalon-dependent project and a long-time lurker
on the Avalon developers' list, I've been extremely concerned by the
recent threads on the list. While conflict is often constructive, I
don't believe the recent threads serve the general good.
There's one point that Noel made that I'd like to expound upon further.
> If this means that there needs to be cleaner lines drawn regarding
> sub-projects such as Cornerstone and Excalibur, then draw them and be
done
> with it. If they are available for ANY containers to use, then they
are
> equally shared. If they are part of a given container's domain, make
it
> clear and let the other containers clone them now.
As I see it this, as much as the personality conflicts, is the root
problem.
We have a couple (perhaps more than a couple) of different visions of
what features and behaviors an Avalon container should provide. That's
good. Contrasting visions, when brought to the larger community, can
help drive innovation and product development. No one has a monopoly on
good ideas (and, as is less often stated, no one is immune from at least
the occasional bad idea).
We have strong personalities driving those visions. That's also good -
strong advocates are important. Otherwise ideas die on the vine.
What we don't have is a clear exposition of those visions, their points
of intersection, and their points of divergence. Maybe other people on
this list feel differently, but I believe that a lot of this could be
resolved by a frank and open technical discussion under Apache
guidelines. I'm still not clear what specific goals the members of each
group are trying to achieve. It would also be an opportunity for those
of us who are Avalon consumers to bring to the developers' attention
some of the things that we find most confusing/inadequate (i.e.
identity/typing of objects provided in the context).
The goal of this discussion would be to precisely delineate what falls
into the framework and what does not. The framework constitutes the
common services available in and behaviors provided by all Avalon
containers. Note that the Framework is not only the set of interfaces,
but is also a clear statement of the container-component contracts that
those interfaces represent.
Anything outside of the framework scope may or may not be provided by a
container. "Extras" provided by a particular container may later make
it in (perhaps in altered form) to a later rev of the framework. Anyone
who writes code that depends on a container-specific feature is
committing themselves to that container. This is exactly how the world
of commercial app servers works.
As far as the impact on the codebase, the end result of such a
discussion would be a set of framework classes and Apache/Jakarta
commons classes which are common, and several sets of container specific
classes in different, non-conflicting container specific packages. In
the end, render unto Framework what is Framework's, Commons what is
Commons, Phoenix what is Phoenix's, and Merlin what is Merlin's.
Yes, such a discussion would be a distraction from writing code. And
some tend to view discussions like this as a waste of time. But Avalon
has grown into a diverse and active community, with a number of
"customers". That means it needs to devote real time to discussion of
these high-level issues. Otherwise, IMHO, more lovely and unproductive
email battles are inevitable.
On a not quite related note, another reason for this discussion is that
it might serve as the basis of new Avalon marketing documentation. This
marketing effort would serve to solidify current users and attract new
ones. This would help spread the Avalon vision as well as making Avalon
evangelizing easier for those of us on products where there is a "ditch
Avalon" movement. Just a thought.
--Peter
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>