excalibur-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Peter Donald <pe...@realityforge.org>
Subject Re: Another Development List?
Date Sun, 11 Jul 2004 07:03:47 GMT
Leo Simons wrote:
> With regard to me moving some code around in the main trunk (of which 
> apparently one or two commit messages haven't made it to the svm list), 
> we briefly discussed it as part of the "Excalibur != Component 
> Repository" thread and there were no objections then. If there's a 
> reason why this is a bad idea please say so and its easily reverted.

I don't think there will be a problem with moving code around as such 
but I think that you should at least engage the community before you 
start restructuring a repository.

This is especially true when it is just going to create more work for 
others if they are not given enough notice. I had uncommitted files that 
I was playing around with and it was a PITA to go through the steps in 
updating my local setup. Subversion also does not deal well with things 
like inability to delete local directories that are deleted in remote 
repo due to local files that were not version controlled.

In the end I had to spend about 30 minutes fixing up my local repo and 
this could have been avoided if I had been given warning that such a 
global change was imminent.

> A "commit-then-review" way of doing things involves reverting things 
> every now and then, which is now less of a hassle than when we were 
> doing CVS. I've found this style of development can be very efficient if 
> everyone is fine with it. Since it sounds like you don't like it, we can 
> put a stop to it. What do others think? Is "commit-then-review" a bad idea?

Commit then review is fine except for design changes or changes that are 
likely to break other peoples code. (Branches are much more 
free-for-all). The change in structure is what I would call a design 
issue. I think people should be allowed to have an opinion on a change 
like this before it occurs.

Theres several questions that I would imediately ask;
* Why re-use the term containerkit?
* Why is the instrument part of containerkit? (It is independent of 
containers and could easily sit in its own hierarchy)
* Why is Lifecycle part of containerkit? Presumably Avalon/Merlin have 
forked a version of this by now and thus would it not make sense to 
migrate Lifecycle to fortress?
* Why is Logger in containerkit and monitor not?
* Why separate out deprecated elements? Isn't that going to lead to more 
churns as components are moved between different lifecycles? WHy not 
break the hierarchy up in how they are used? (ie why not have ecm/, 
fortress/, instrument/ etc as base dir names)

yadda yadda yadda

The answers are not as important as the ability to ask them and for each 
of us given the chance to influence how the changes are implemented.

> With regard to the experiments hammett is doing, I hope its been made 
> clear that they are just experiments, and that we agree this radical 
> stuff isn't actually the way forward. From my own experience, dabbling 
> with writing a different container or two can be a good way to better 
> learn the way existing containers work, and I have no problems with it 
> going on over here.

To be honest I have not looked at it and I really don't have any problem 
with whatever is occuring there. I have written a couple of interceptor 
toolkits myself and know how much work and pain it can be so I think 
hammett is probably doing a lot fo work that we should be thankful for.

However I would also be very concerned that one of the many numerous 
"AOP" toolktis were not considered. Many of them are relatively mature 
products that have already gone through several development cycles. They 
are going to be faster, better supported and more versatile than the 
toolkit in excalibur simply because they have had many more development 
hours funneled into them. No offense intended hammet ;)

If they are innapropriate (ie licensing, architecture or whatever) or we 
simply decide to reinvent for fun then thats fine but there should be 
some discussion about it.

Theres no use in drowning the project in beuracracy so that every change 
is a PITA but there should at least be some active discussion on whats 
going on and what people intend to do etc.


Peter Donald
| You can't wake a person who is pretending      |
|       to be asleep. -Navajo Proverb.           |

To unsubscribe, e-mail: dev-unsubscribe@excalibur.apache.org
For additional commands, e-mail: dev-help@excalibur.apache.org
Apache Excalibur Project -- URL: http://excalibur.apache.org/

View raw message