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 [EMAIL PROTECTED]
- verba volant, scripta manent -
(discussions get forgotten, just code remains)
---------------------------------------------------------------------
--
To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]>
For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
