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? Kind regards Juergen --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
