Harmeet,

> One of the problems with this checkin is that that each person has his/her
> own views.

> I don't think recent changes are bad. James is now moving better than in
> past, but an overall standard way or an exchange on what should be the
> right way may be better.

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?

> If each person decides to refactor/rearchitect on instinct or even in
> response to terrible issues, it would be a bit of loop assuming any
> software would have issues and will(hopefully) outlive it's develepers.

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.  Look at the major architectural change from Cocoon v1 to Cocoon v2.  In
some cases, the architecture was changed by the original author, in other
cases it was changed by someone else.  In either case, the architecture
changed in response to needs.

If you have a problem with an architectural change, I think it is absolutely
right and appropriate to raise the issues and for developers to discuss the
merits.  When people have had issues, I've seen them discussed here.  Some
of have been acted upon, others are pending (for example, a whole bunch of
us want to discuss the next generation of Mailet support, but we've all
agreed to put it off until after the next release).

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?

With respect to the various recent changes, how do you consider that they
were the work of any one person?  A number of people discussed the various
issues over a period of time.  Andrei contributed initial changes for
services and connections, Steven Short and Shilpa contributed changes to
LinearProcessor.  Various people have been working on IMAP.  Peter has
worked on finalizing a number of them to the point where, as a Committer, he
felt that they were in a condition that he'd be willing to support.  True,
the commit did often lag behind the discussion by weeks or months, but it
seems to me that generally when the changes were readied, they were first
proposed for review and critique, and then only committed after no
objections.

Are you just raising a general issue of who gets to make changes, when and
how?  Is there something different that you'd like to see than the process
being observed?  As I understand it, Committers are the arbiters of change.
If a Committer wants to veto a change, they issue a -1.  If they don't say
anything, as I understand it from Danny, that indicates passive acceptance.
When changes have been proposed recently, I have only see one -1.  It was
from Danny, and he withdrew it after realizing that he'd misread the change.

Can you clarify your concern, and your thoughts about how they can be
addressed?

        --- Noel


--
To unsubscribe, e-mail:   <mailto:[EMAIL PROTECTED]>
For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>

Reply via email to