james-server-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Danny Angus" <da...@apache.org>
Subject RE: Changes ... who, when, how?
Date Thu, 10 Oct 2002 09:11:59 GMT

> Of course, each person has his or her own views.  Why is this a 
> problem, per
> se?  Your second sentence is that you don't think the recent changes are
> bad.  So then what is the problem you are concerned about?

I think the problem is that although we operate in a "commit then review" fashion, it is naieve
to think that this alone is enough, there should be open discussion of intention and reasoning
for significant re-factorings. Otherwise, as Harmeet says, we could end up in a loop with
competing architectures continually replacing one another. Of course we're not going to be
that stupid, but it doesn't mean we shouldn't air our views for discussion first.

> There is always turnover in Open Source projects.  Things change.  Look at
> the changes from mod_jserv to mod_jk to coyote, or Tomcat 3 to 
> Tomcat 4.1 or
> 5.

I bet it was well discussed first, and some sort of consensus reached.

> I don't believe that anyone decides to re-factor / re-architect "just
> because."  Generally, I think that people have good reasons and express
> them.  I doubt that there will be a loop unless there is conflict amongst
> developers, and I thought that "The Process" covers that issue.  No?

If strictly applied it should;

http://jakarta.apache.org/site/source.html

if you read para "Status files" you'll see we haven't been using a status file to track work
in progress nad short term plans.

if you also read para "Changes" it makes it quite clear that there should be discussion and
consensus on major changes, and any commiter can veto any commited change.

> If a Committer wants to veto a change, they issue a -1.

I think Harmeet is implying, and I would agree with, is that it shouldn't be beyond the bounds
of realism to expect a reasoned discussion of the issues *in advance* to prevent us from ever
getting into the position where a change, once commited, is vetoed. 

d.


--
To unsubscribe, e-mail:   <mailto:james-dev-unsubscribe@jakarta.apache.org>
For additional commands, e-mail: <mailto:james-dev-help@jakarta.apache.org>


Mime
View raw message