[Dev] Problems when external/ and/or internal/ out of sync with chandler/

[Mike Taylor]

On Mar 6, 2006, at 4:47 PM, Heikki Toivonen wrote:

> Here are some things that won't work:
>
> 1. Have full build Tboxes do only make tests and no chandler tests.
>    - won't work because then we wouldn't know when the full builds were
> broken

agree - a non-starter -1

> 2. Change full build make install step to copy the binary tarballs into
> downloads dir. Then doing make install would simply unpack those.
>    - won't work because when the full and quick builds are out of sync
> the make install in chandler/ would cause a prebuilt binary tarball to
> be downloaded, which wouldn't work for all platforms and isn't what we
> want the full builds to do anyway

I could go for this since it is rare that someone is both developing a 
changed library and on a non-supported library.  But I actually like #3 
better so would still give this a -1

> 3. Put each of the external and internal libs on a dev branch. By
> default, the full build would only build trunk. If you passed in 
> DEV=all
> it would do the dev branches instead (or DEV=lib1,lib2, ... to limit
> it). Tinderbox could do default build and all tests, including 
> chandler,
> first. Then do DEV=all build and do only make tests in external/ and
> internal/. After the developers were happy with the dev branch they
> could merge into the trunk and simultaneously update chandler/ dir. The
> only way to update external and internal on trunk would be to merge 
> from
> a branch, so that the trunk and branch would not differ after a merge.
> Just pulling from svn would only get root level external/ and 
> internal/,
> and make sources would then pull the appropriate branches for each of
> the libs.

I like this one a lot, with one small change :)

The change I would make is what we started to discuss on #chandler.  
That there be a environment var that controls what libraries are pulled 
from the branch (heikki suggested something like DEV=m2crypto,zanshin 
which I like.)  This allows a dev to work on the lib they are 
interested in and *not* get hung up on other branch work for libs they 
are not interested in.

Also, to clarify something, *all* release, checkpoint, milestone, 
whatever is done only to the trunk and that the merge only happens from 
the branch to the trunk.  This allows all new library updates to flow 
in one direction and will greatly simplify the merge mechanics.

---
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/chandler-dev/attachments/20060306/b7cb43ce/PGP.pgp