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
