Changes ... who, when, how?

["Noel J. Bergman" <no...@devtech.com>]

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:   <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>

RE: Changes ... who, when, how?

["Noel J. Bergman" <no...@devtech.com>]

Harmeet,

There has been discussion, but judging from various people's comments, there
is interest in the dicussion.

> Some of my reaction stems from (a) AuthService ...

AuthService is a different issue not related to the this refactoring of
Services and Handlers.  We shouldn't transfer concerns between unrelated
areas, unless you see a real connection.

> (b) refactoring commits that seemed to be philosophy driven

More than just philosophy.  I don't think that they are simply isomorphic.

In any event, since the code was posted for purposes of review and
discussion prior to being committed, seems to me that we're spending more
time discussing the discussion, whereas you want to be discussing the code
over the weekend.  So let's discuss the code.  :-)

And I thank you for the compliment.

	--- Noel

-----Original Message-----
From: Harmeet Bedi [mailto:harmeet@kodemuse.com]
Sent: Friday, October 11, 2002 13:01
To: James Developers List
Subject: Re: Changes ... who, when, how?


----- Original Message -----
From: "Noel J. Bergman" <no...@devtech.com>

> I agree, but I fail to see the problem.  In the case of the watchdog and
> service changes, (a) I believe that there has been prior discussion, (b) I
> believe that after the code was changed based upon prior discussion, it
> was specifically posted for the purpose of inviting further discussion,
> and (c) it hasn't committed before discussion.

I apologize to all esp. Peter if this has been discussed and agreed on
before.
I don't think it is the right fix, but if the list has been through this, no
point in revisiting.

However if this has not been agreed on before I'd prefer if the
Scheduler/Service rearchitecture changes are held off for at least 2-3 days.
I would like to chat a bit more about this. - thanks.
Some of my reaction stems from (a) AuthService(bad bug but that should not
have resulted in Auth and Handler coupling) changes where a discussion was
started and concluded in checkin before any consensus. (b) refactoring
commits that seemed to be philosophy driven - again not bad but there is
very little point in silently changing a part of existing philosophy.


Harmeet

PS: Hey Noel, you seem to be a really good facilitator. :-)


--
To unsubscribe, e-mail:   <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>

Re: Changes ... who, when, how?

[Harmeet Bedi <ha...@kodemuse.com>]

----- Original Message -----
From: "Noel J. Bergman" <no...@devtech.com>

> I agree, but I fail to see the problem.  In the case of the watchdog and
> service changes, (a) I believe that there has been prior discussion, (b) I
> believe that after the code was changed based upon prior discussion, it
was
> specifically posted for the purpose of inviting further discussion, and
(c)
> it hasn't committed before discussion.



I apologize to all esp. Peter if this has been discussed and agreed on
before.
I don't think it is the right fix, but if the list has been through this, no
point in revisiting.

However if this has not been agreed on before I'd prefer if the
Scheduler/Service rearchitecture changes are held off for at least 2-3 days.
I would like to chat a bit more about this. - thanks.
Some of my reaction stems from (a) AuthService(bad bug but that should not
have resulted in Auth and Handler coupling) changes where a discussion was
started and concluded in checkin before any consensus. (b) refactoring
commits that seemed to be philosophy driven - again not bad but there is
very little point in silently changing a part of existing philosophy.


Harmeet

PS: Hey Noel, you seem to be a really good facilitator. :-)


--
To unsubscribe, e-mail:   <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>

RE: Changes ... who, when, how?

["Noel J. Bergman" <no...@devtech.com>]

> I think the problem is that although we operate in a "commit then review"
fashion

Except for one thing: the code isn't committed!  It WAS posted for review.
The message from Peter included the proposed code, a description of what and
why, and then concluded with:

"I've done basic testing on this code, and I am now doing further load
 testing.  I will continue to do testing BEFORE SUBMISSION [emphasis mine].

[clip]

As always, comments, critiques, and questions are welcome."

As I recall, the changes were made from open discussion over the summer, and
based upon input from several folks, although I guess no one formally called
a vote.

> there should be open discussion of intention and reasoning for significant
re-factorings.

I agree.  Seems to me that that's exactly what is (and should be) happening.
At least that's how I interpret his action to post the code for comments,
critiques and criticisms before he commits it.

That is the point of Harmeet's that confuses me.  I'm confused about the
issues of why wasn't this discussed before, and why wasn't it discussed
before committing, because it seems to me that neither of those is correct.
The code WAS posted for discussion, and before that, I recall discussions of
watchdog timers and service re-factoring.  Andrei submitted the original cut
of service changes months ago.  Perhaps it would have been good if Peter had
kept more of a running dialog going over the intervening period, but I
didn't perceive any of the changes to have come out of a vacuum.

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

Thanks for that, and the rest of the elaboration.  How do we address the
"Status Files"?

> 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.

I agree, but I fail to see the problem.  In the case of the watchdog and
service changes, (a) I believe that there has been prior discussion, (b) I
believe that after the code was changed based upon prior discussion, it was
specifically posted for the purpose of inviting further discussion, and (c)
it hasn't committed before discussion.

	--- Noel


--
To unsubscribe, e-mail:   <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>

RE: Changes ... who, when, how?

[Danny Angus <da...@apache.org>]

> 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:   <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>