james-server-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Vincenzo Gianferrari Pini <vincenzo.gianferrarip...@praxis.it>
Subject Re: AW: AW: [VOTE] Using of 2.3 branch
Date Thu, 21 Dec 2006 17:22:16 GMT

J├╝rgen Hoffmann wrote:
> 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?
>   
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: server-dev-unsubscribe@james.apache.org
For additional commands, e-mail: server-dev-help@james.apache.org


Mime
View raw message