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: [VOTE] Using of 2.3 branch
Date Thu, 21 Dec 2006 17:02:31 GMT
Stefano Bagnara wrote:
> Vincenzo Gianferrari Pini wrote:
>> 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*.
>
> Imho mantainability depends on how much people is committed to the 
> process of a given release. If we had 100 committers I would have no 
> problems in having 10 branches.
True.
>
> Imho the problem in this thread is the mixed issue of the v2.3 branch 
> and a release created starting from the v2.3 branch.
True.
>
> If I understood Norman's intentions for calling this vote, it is not 
> about next-minor, but simply about the use of the "v2.3" branch we 
> have in the repository.
>
> When I vote -1 to use "v2.3" for new features I mean that I don't want 
> that branch to be used for features, but I'm not against the creation 
> of a release based on the v2.3 branch. I simply think that this 
> deserve a PROPOSAL (concrete, with issues to be backported list) and a 
> custom branch. Maybe that we'll never use the v2.3 for another 
> release, but I don't think why to reuse branch names on svn. It seems 
> to me simply following good practice.
>
>> 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.
>
> You should do this in trunk. Trunk is where development is done. After 
> you have done this in trunk we can discuss wether to backport it to 
> some branch.
And I will do it that way. But then I need to immediately backport to 
2.3 (or 2.4), because I have to deliver it to a Client with my extension 
(I'm using this as an example, but is real :-)  ).

For me it's all the same: the only difference is that if we have 2.3, 
2.4 and trunk we have to backport twice any fix. But let's then create a 
2.4 branch.

FWIW, there is a missing functionality in SVN compared to SourceSafe: 
the *share/split* concept. It would allow a much easier common 
management of two very similar branches as 2.3 and 2.4 would be. When I 
talked about that to the SVN people in ApacheCon Europe, they simply 
didn't know it and then said that it's a matter of habit, but it's not 
true. Anyway this is not pertinent to James... :-)
>
> This is why backporting can be done with a vote after a proposal 
> including the list of intended backports is done. As I said I prefer 
> RTC for the v2.3 branch, but I'm not against using CTR: I thought that 
> people that loose time working on that code would be happy to know 
> ASAP if I will vote -1 to a release including what they just 
> backported. Of course a single -1 will not block the release, but a 
> majority of -1 will do, so it is better to understand each others and 
> define the roadmap.
What are RTC and CTR :-)  ?
>
> My concern with backporting features is that a LOT of bugfixes (either 
> minor or major) have been done in trunk, and I think that selectively 
> backporting all the bugfixes is already a really big task wrt a point 
> release. I wouldn't like to make a release with backport of minor new 
> features but not backports for bugfixes we did.
>
> Stefano
>
>
>
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