james-server-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From J├╝rgen Hoffmann ...@byteaction.de>
Subject AW: AW: [VOTE] Using of 2.3 branch
Date Thu, 21 Dec 2006 16:58:19 GMT
Hi Vincenzo,

see inline...

-----Urspr├╝ngliche Nachricht-----
Von: Vincenzo Gianferrari Pini [mailto:vincenzo.gianferraripini@praxis.it] 
Gesendet: Donnerstag, 21. Dezember 2006 16:04
An: James Developers List
Betreff: Re: AW: [VOTE] Using of 2.3 branch

*We* comitters should be wise enough to judge and make the decision 
individually, and the commit can be withdrawed any time after a veto (or 
simply after a short discussion on the list). We should just be not 
touchy if it happens.

[JH>] Open Discussion about introducing features, whether minor or major, on
the mailinglist is fine. Although I think this should be done beforehand. This
removes the need for a separate "feature" Branch. This kind of discussion
should be held beforehand though.

I especially liked the "touchy" citation, since I used it in another context
some time ago ;)

Agree, but at the same time having three branches is hard to mantain (we 
know that from the past history of James), so what I think is worth is 
to all of us be more *flexible and pragmatic*.

For example, I have in mind (and have a personal need) to put inside the 
appropriate places of RemoteDelivery calls to two empty (just returning) 
protected methods called onSuccess and onError (or some similar name), 
to be able to build my own  personal extension "MyRemoteDelivery" 
(inside a jar in SAR-INF/lib) that would log into an application 
database the outcome of the delivery. I need and want to use 2.3.1 or 
2.4.n. The featrue is very "minor", in the sense that the code change is 
very simple and safe. But I have not yet done it because I don't know 
where to put it, so I may end up writing my own modified RemoteDelivery 
mailet instead of using the official one plus my extension.

[JH>] see above. I think it is necessary to discuss new features to be
introduced into a certain branch beforehand. One might miss a commit, because
he is on a convention for a week, and with the discussion beforehand, the
community already has come to a certain understanding and consent why this
feature should go into the branch.

And another thing about minor changes. A minor change is always capable to
break something somewhere else. No matter how big the change, things have to
be tested thoroughly. The fix for a mission critical Bug, should always be
released, even without further features within the branch. 

To grab your example. Think about the committer who has written the feature
you are talking about. He might miss to release the connection. No one notices
it. A Bug comes in, that needs to be fixed, is fixed and released. Another
user reads about the new feature within the bugfix release, thinks COOL I need
this. Bang memory leaking Mailserver.

See the point?

Kind regards


To unsubscribe, e-mail: server-dev-unsubscribe@james.apache.org
For additional commands, e-mail: server-dev-help@james.apache.org

View raw message