[Dev] Branch or not branch for wx incremental integration

[Mike Taylor]

Using SVN the maintenance of the branch is actually quite easy - you 
just do daily or twice daily merges from the trunk to the branch to 
keep the branch in sync with the non-wx code.  This step becomes the 
following sub-steps:

	- get the starting revision number (which should be mentioned in the 
commit message of the last merge)
	- get the ending revision number
	- craft a commit message that references the merge command
	- merge and resolve any conflicts

Since David will be working in wx and no one else really does there 
should not be many conflicts.

The part that will become more complex, IMO, is testing -- the merge 
will need to be tested to make sure any new CPIA code works properly 
with the new wx code.

If the testing is done regularly then the final merge back into the 
trunk will also be straight-forward (I hesitate to say easy knowing how 
wx changes :)


On Oct 19, 2005, at 1:55 AM, Philippe Bossut wrote:

> Hi,
>
> With the upcoming 0.6 release and the necessity for stabilizing the 
> code base (getting to zarro bugs), it's going to be risky to do "wx 
> incremental updates" as we've been doing in the past. On the other 
> hand, this method of incremental updates really makes David's work 
> easier compared to big wholesale update of wx and allowed us to enjoy 
> some nice bug fixes (focus issues and drag'n drop in particular).
>
> We discussed this at length during the Apps meeting today and we 
> thought that a possibility would be for David to continue to do the wx 
> incremental updates in a branch. We'll then be able to evaluate the 
> continuous improvements of wx, experiment with the wx 2.7 code base 
> and avoid the big "port" at the end of the wx release cycle (scheduled 
> for December). We'll also be able to test if a particular 0.6 bug is 
> really "fixed" by some recent wx patches and make decisions 
> accordingly. Eventually, after 0.6 is declared and branched, we will 
> merge the wx branch into the trunk (one of the first 0.7 things we'll 
> do). Ideally, the wx branch is kept in sync with the 0.6 trunk so the 
> final merge is easy (a little bit as we did for the set_collection 
> branch in m5). That's extra work for David though and, considering the 
> amount of commit we see these days, a sizable one.
>
> I realize that this will require some additional work for some of us 
> (David and Bear mostly, but also Aparna) as any branch does but we 
> need to make that decision within the next week really if we want to 
> do that.
>
> So, to summarize the choices we have in front of us are:
> (a)- stop doing incremental updates altogether (and face a big ugly 
> port when starting 0.7)
> (b)- continue the incremental updates in the trunk (and pray nothing 
> will go horribly wrong in the 0.6 debug phase...)
> (c)- do the incremental updates on a wx branch and merge post 0.6 (and 
> pay a continuous extra maintenance cost during the 0.6 debug phase...)
>
> I personally think (c) is the best choice but we need to really 
> thought it through.
>
> So, I'm opening the debate here: what do you guys think? are there any 
> brilliant alternatives we haven't thought of?
>
> Cheers,
> - Philippe
> _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _
>
> Open Source Applications Foundation "Dev" mailing list
> http://lists.osafoundation.org/mailman/listinfo/dev
>
>
---
Bear

Build and Release Engineer
Open Source Applications Foundation (OSAF)
bear at osafoundation.org
http://www.osafoundation.org

bear at code-bear.com
http://code-bear.com

PGP Fingerprint = 9996 719F 973D B11B E111  D770 9331 E822 40B3 CD29


-------------- next part --------------
A non-text attachment was scrubbed...
Name: PGP.sig
Type: application/pgp-signature
Size: 186 bytes
Desc: This is a digitally signed message part
Url : http://lists.osafoundation.org/pipermail/dev/attachments/20051019/17c50b59/PGP.pgp