Proposal: Add v3-4-test to the build farm, and revamp the build farm policy

[Tim Prouty]

On Mar 17, 2009, at 12:54 PM, Tim Prouty wrote:

> On Mar 17, 2009, at 3:15 AM, Stefan (metze) Metzmacher wrote:
>
>> maybe we could use:
>> samba_3_X_stable for the -test branch of the current release (v3-3- 
>> test)
>> samba_3_X_test for the -test branch of the next release (v3-4-test)
>> samba_3_X_devel for master
>
> Metze, I didn't consider the added cost of using the explicit branch
> names.  I agree that it makes sense to have symbolic names to avoid
> the overhead of making future changes multiple places in the build
> farm scripts.  I do think the current mappings should be somehow
> displayed on build.samba.org.  Maybe they already are, and I just
> don't know where to look :).
>
> I'm much more concerned with what branches are being built than their
> names in the buildfarm, but since it's up for discussion, here are my
> naming suggestions:
>
> I still think it would make sense for the following rename:
> samba_3_X_devel -> samba_3_master
>
> This branch isn't tied to a particular release so the 'X' isn't really
> necessary, and 'master' label shouldn't change until we move to the
> next latest and greatest version control systek.
>
> The 'test'/'stable' lables are a bit confusing since those names
> conflict with names of actual git branches.  What if the names were:
> samba_3_cur_release
> samba_3_next_release
>
> If it's too much work to rename the existing branches, I can live with
> the current naming scheme (plus the new branch) as long as the mapping
> is well documented.
>
>
>> But we need to decide which ones we want to build on machines with  
>> low
>> disk space.
>
> It's a no-brainer that all build farm nodes should be building master.
>
> For the disk-space-limited build farm nodes, that leaves one
> additional branch to be built.  The two options are:
>
> v3-3-test (cur): Since maintenance releases are cut (almost)  
> directly from
> this branch it's important that it is building and running cleanly on
> all systems.  On the other hand, there should be very little code
> churn on this branch, so it is kind of wasting resources to choose
> this option.
>
> v3-4-test (next): There will be significantly more code being  
> checked into
> this branch, and regularly building and testing it will help stabilize
> the branch more quickly.
>
> My vote is to build v3-4-test when only 2 of the 3 branches can be  
> built.

Metze (or anyone else), any thoughts on this?  Metze, let me know how  
I can help implement these changes.

-Tim