ode-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Maciej Szefler <...@intalio.com>
Subject Re: NOTICE: trunk may be buggy this morning.
Date Tue, 15 Aug 2006 17:39:25 GMT
In general I'd prefer less discussion rather than more, applying the
following rules:

1. deviations that get us closer to an established goal do not require

2. ditto for refactors / improvements of existing functionality

3. new core features where there may be disagreement as to the
requirements require some discussion beforehand.

4. non-core features should not require discussion unless they are found
be a nuisance or until it is determined that they are in fact core

1. e.g. my tweaks to deployment
2. e.g. go through BpelServerImpl and fix the multi-threaded concurrency
3. e.g. versioning, content api, business transactions, etc...
4. e.g. implement a debugging facility, support additional query
language, etc..

All these are subjective of course. If something more rigid is called
for then we might consider establishing ownership responsibilities for
certain areas of the project so that we don't have to get bogged down in
endless discussions. Of course there would always be recourse to
democracy: if for example there is a big disagreement that cannot be
worked out between someone working on the engine, and the API owner,
then this nuclear option is always available. 


On Tue, 2006-08-15 at 10:37 -0600, Lance Waterman wrote:
> Maciej,
> I am trying to understand expectations around how the ODE project
> plans to work. Based on past exchanges you made the following comment:
> >>I think the versioning changes will require an understanding of how
> the 
> >>feature would be implemented -- a design reveiew. As for the scratch
> vs
> >>patch, scratch is called for when multiple developers are going to
> be
> >>involved in developing a feature.
> and Alex made the following comment: 
> >>An idea: you could also create a temporary branch to make it easier
> to
> >>share, collaborate and merge/synchronize the code if you think the
> scope
> >>warrants it. 
> Now I think I hear you saying that the interface is not stable and
> folks should not be surprised if it should change ( i.e. adding
> versioning ) without notification/discussion and at some future point
> in time we may decide to lock it down. 
> I find the following comment subjective:
> >>but on the whole I feel
> >>that the changes I made were only getting us closer to the intent of
> the
> >>group WRT deployment.
> So I am struggling with expectations around design/interface changes.
> I personally would like to see discussion around changes to the public
> interface before being checked into the trunk. For example; I would
> like more information around some questions I had on methods added to
> the BpelServer interface. 
> However, if there is consensus that the group would rather work within
> a more fluid environment that is fine with me. In this more fluid
> environment I don't think we can fault folks for their subjective view
> on interface/implementation changes and the only thing we can do is
> ask questions and make suggestions after the fact. 
> Again, I can work in either environment but I would really like to
> hear from folks and come up with a consensus on how they see the
> development process working.
> Thanks,
> Lance

View raw message