I can work with David to setup and test his branch dev environment so it's as straight-forward as possible.

We can even start and test using some smaller updates to see how the flow will work - but I'm sure it will be ok. This is the pattern than a lot of other SVN shops use for third party vendor updates.


On Oct 20, 2005, at 2:46 AM, David Surovell wrote:

Philippe,

I'll go for c), provided that someone helps me get my svn environs working on Mac and Win.

Regards,
David S.

=================

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)
[EMAIL PROTECTED]
http://www.osafoundation.org

[EMAIL PROTECTED]
http://code-bear.com

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


Attachment: PGP.sig
Description: This is a digitally signed message part

_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _

Open Source Applications Foundation "Dev" mailing list
http://lists.osafoundation.org/mailman/listinfo/dev

Reply via email to