> 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:[EMAIL PROTECTED]> For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
