[Dev] Branch or not branch for wx incremental integration

[Philippe Bossut]

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