avalon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Berin Loritsch <blorit...@apache.org>
Subject Re: Politics
Date Wed, 30 Apr 2003 13:50:41 GMT
Peter Donald wrote:
> hi,
> On Sat, 26 Apr 2003 19:37, Neeme Praks wrote:
>>Can we clean this mess? Just write down the things that are bothering
>>you and then we can address these issues.
> I just wrote a long email on all the problems in Avalon and it ended up 
> several pages long. Basically the same points I have been complaining about 
> for ages. Some of those problems are unlikely to go away. Rather than repeat 
> it all maybe it is best to say what I think is best for Avalon.
> Basically we still have one man code bases, crapola code, and other stuff that 
> is only going to cause conflict. I propose that almost all component 
> development gets done elsewhere (though we can do link back) where it is more 
> healthy environment. I would suggest jakarta-commons in most cases if 
> collaboration is the goal of components. I would propose that the only 
> solution is to get back to a single code base that everyone accepts and will 
> work on. So we burn away all other code in Avalon so that there is just the 
> following;

Keep in mind that all of these things have to be done in accordance with
the community dynamic.  We are a team, and we need to work as one--I
have some ideas for moving forward, but we also need to resolve some
other issues in the short term first.

Let the team decide what they want to keep, and if they decide to keep
it, they decide to maintain it.

> avalon-site
> avalon-framework
> excalibur-fortress
> excalibur-lifecycle
> excalibur-instrument(* ???)
> excalibur-logger
> excalibur-pool (but we deprecate this - and possibly merge into following)
> excalibur-component (but we deprecate this)
> excalibur-compatability (but we deprecate this)
> and possibly avalon-logkit.

I noticed that you removed some things that Fortress depends on, but
kept fortress.  For one, the SourceResolver.

This code is now maintained by us, and we use it, so we have a vested
interest in it.

> We also move to maven as build system to stop the chances of code getting 
> broken due to poor process. We can use it to enforce certain quality controls 
> and release processes.

I think this is a separate issue that we can address separately.  I
agree in principle, but I need to get an install that just works.

> We also start requiring that people accept responsibility for their actions. 
> We can also implement some process that stops people chronically breaking 
> code or our website as is currently the case. Maybe going as far as removing 
> privs of those who wont shape up.

That responsibility goes both ways.  Perhaps we should put a timer on
someone and if they don't fix it within 30 seconds of someone else
noticing the mistake we fire them.  Oh, wait a minute, how is that other
person going to know when someone else notices the mistake?

Perhaps there is a reason for more than one day without the issue being
resolved?  It pays to find out what is going on before we run around
with a loaded gun and arbitrarily removing commit privs.  That is a very
serious action, and it should never be done lightly.

> The effects of this will be to vastly improve dynamics here as it removes all 
> the codebases that have caused conflict and will establish Avalons focus on 
> codebases that almost all of the active Avalon developers have worked or 
> collaborated on. Otherwise I can't see any other way that we will ever return 
> to a healthy project status. 

There was this guy who felt guilty that his temper always flared up.  He
decided that it was time to do something about it.  He figured that if
he removed all the things that caused him to be angry for a while that
he could conquer that anger.  He took a job as a forrest ranger in the
Yosemite, and for a period of an entire year he was not angry once.  Of
course he never had any contact with other people in that period either.
After the year was up, someone drove up to give him his provisions for
the next year.  The guy driving the truck said something in a joking
manner, but it was taken the wrong way.  Our angry person went off,
yelling with all the anger he had before.

The moral of the story is that removing all the current causes for
conflict doesn't solve the problem.

You have to deal with it, and work it out.  Provide some give and take.
Use the art of compromise to find a happy medium.

> In time if this is successful and people start collaborating again then we can 
> establish an Avalon-Commons (though personally I think it would be far better 
> to still do it in Jakarta-Commons).

We must be reading two different lists, because I am not seeing what you
are seeing.  Truth be told, you are the only one pushing for Avalon
components over on Jakarta Commons.

To unsubscribe, e-mail: dev-unsubscribe@avalon.apache.org
For additional commands, e-mail: dev-help@avalon.apache.org

View raw message