Jürgen Hoffmann wrote:
Hi Vincenzo,
see inline...
-----Ursprüngliche Nachricht-----
Von: Vincenzo Gianferrari Pini [mailto:[EMAIL PROTECTED]
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?
Just being specific on the example, the change to RemoteDelivery would
be two calls to two new empty methods, while all the potentially
"dangerous" code (handling jdbc connections etc.) would stay in another
Mailet class that I would keep private and not commit in James.
Otherwise I agree it would not be a "minor and safe" thing at all :-) .
Kind regards
Juergen
Ciao,
Vincenzo
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
