[Chandler-dev] Re: wx build/merge/test thoughts

Heikki Toivonen heikki at osafoundation.org
Fri Apr 21 14:08:59 PDT 2006

Replying to dev with Robin's peremission. I've included all of what he
wrote, and I am responding to specific sections.

Robin Dunn wrote:
> I've had some thoughts over the past few days about the process of
> getting wxWidgets code into Chandler.  I know that others have been
> thinking about improvements to the trailing edge of the process
> (building and testing with incremental builds, rolling tarballs,
> functional tests, getting new versions into chandler, and etc.)  My
> thoughts have been more on the leading edge of the process, that of
> getting wx updates into the repository, merged with the OSAF changes,
> and so on.  So far this is just a bunch of random thoughts that are just
> now starting to gel together, so if any of it doesn't make sense, or is
> not possible or feasible, then feel free to shoot it down with flaming
> arrows without worry of hurting my feelings.  ;-)
> So anyway, I'm thinking that we should try to leverage the abilities and
> tools that subversion gives us as much as possible.  (Also, I'm still
> pretty much a newbie with subversion as this is the only project I've
> had a chance to use it on so far, so some of this may be wrong...)
> Subversion makes it fairly easy to make branches and switch between
> them, (much easier than CVS) and branches are also a low cost since only
> the files that are different between branches require any additional
> work by subversion.  Also, subversion is supposed to be better at
> handling merges and doing the right thing more often than CVS, although
> I haven't experienced this yet to say for sure.
> My idea is that we have a couple extra branches for wx in addition to
> the trunk.  The first branch would be an exact copy of the wx CVS, let's
> call it "stock_wx" or something like that.  The reason to do this is to
> have the stock version of the code under subversion's control so it can
> easily be used as a source of a merge.  This branch could be updated
> daily from wx CVS via an automated script that does a cvs update, runs
> some test builds or etc. and then commits it to the subversion
> repository.  If the script is smart enough then it can extract the
> commit log messages from CVS for the time period it is updating, and
> then use that as the subversion commit message.  There should be no
> other commits on this branch.

I think this is a great idea.

> The second branch could be branched from stock_wx (too keep the history
> correct) and would contain the wx source tree with the OSAF
> customizations applied, so let's call it "osaf_wx".  This is where the
> work is done by David, John, myself and any others at OSAF who are
> working on wx itself.  They would probably have their internal/wx
> directory "switched" to this branch most of the time. There should
> probably be a set of tinderboxen that are building and testing Chandler
> using the code on this branch.  Periodically the stock_wx branch is
> merged into the osaf_wx branch (perhaps once or twice a week, or as
> needed to get fixes from wx.)  This can be partially automated (at least
> a script to merge from the last merge-point tag and setting a new
> merge-point tag) but will still need some human intervention to resolve
> any merge conflicts, doing testing, and etc. before checking it in to
> the subversion repository.
> Finally, the wx on the trunk will simply be periodic snapshots of the
> osaf_wx branch.  This is where the code is pulled from for the tarballs
> to be used for the main tinderboxen and for Chandler.  There shouldn't
> be any need for doing merges here, so the script making the snapshot
> could just do a svn copy, increment the tarball relver, commit the
> changes, and then send an email to Bear letting him know it is time to
> get ready because a new wx is coming over for dinner.  ;-)  This should
> help to minimize the impact of changes on the rest of the team because
> the tarball updates won't need to happen as often (unless an update is
> needed to push through important bug fixes or enhancements) and when
> they do happen they should have had some more testing than they have now.

There really isn't any need to require manual intervention from bear. We
have (and will have even better better) automation to deal with this.

> In addition to these extra branches it would be nice if the build and
> test systems could easily adapt to the developers having private
> branches if they need to do some work without interfering with the work
> that others are currently doing.  In my experience this is not needed
> all that often, but when you need it, you *really* need it.  So perhaps
> there could be a set of tinderboxes that could be switched to a specific
> branch on demand.

I think having tinderboxes for these kinds of things would be an
overkill, and not actually as effective as you'd really like it to be.

If you really needed something like this, you'd really need something I
call a build robot, that works something like this:

1. You create a patch/branch for your changes.
2. You send an email to the build robot with your patch and/or branch
3. The build robot compiles the changes and runs tests, and sends you an
email back with the results.

But I think both of these are overkill. You do your best, check in, and
normal Tbox will show what is wrong, and then you fix it.

> There are a couple of potential issues that I see at this point.  First,
> if changes being made in the osaf_wx branch require changes be made in
> Chandler to properly test them, then either the branch has to include
> more than just wx (but that means merging chandler from the trunk to the
> branch,) or ignoring the Functional Tests on the tinderboxes in these
> cases, or there needs to be some way of temporarily patching the
> chandler code used for running the tests on the tinderboxes.

This is a known issue, but something I believe we can live with. The
branch Tbox we are planning in alpha3 would show you if wx changes would
break trunk tests. When you are ready to checkin to the trunk you will
be able to checkin all the changes, including changes in chandler/, in
one checkin so everything will work seamlessly.

> Second, when changes made in the osaf_wx branch are fed back upstream to
> wxWidgets, and then eventually come back through the stock_wx -->
> osaf_wx branches then there will probably be some merge conflicts that
> need to be dealt with.

True, stock_wx to osaf_wx merges will have to be done manually and all
conflicts resolved by hand.

However, it is starting to look to me that there is going to be so much
machinery to deal with wx specifically that it would make more sense to
create a completely new svn repository for wx. From Chandler's point of
view it would become just another external library.

  Heikki Toivonen

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 251 bytes
Desc: OpenPGP digital signature
Url : http://lists.osafoundation.org/pipermail/chandler-dev/attachments/20060421/d32ae335/signature.pgp

More information about the chandler-dev mailing list