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

[Tim Prouty]

On Mar 17, 2009, at 3:15 AM, Stefan (metze) Metzmacher wrote:

> Andrew Bartlett schrieb:
>> On Fri, 2009-03-13 at 12:54 -0700, Tim Prouty wrote:
>>> Hi all,
>>>
>>> Now that v3-4-test has been created, the goal is to aggressively
>>> stabilize the branch and prepare it for release in the next few
>>> months.  Internally we are putting significant QA resources into
>>> testing v3-4-test, and it is my desire to work toward making it rock
>>> solid as the v3-4 release approaches.  To keep the code base stable,
>>> it is critical that v3-4-test is regularly built and tested in the
>>> build farm so that obvious bugs can be caught early and fixed.
>>>
>>> This brings up a larger point that the build farm names aren't very
>>> well mapped to the new release model that has been adopted.  For
>>> example, while it's important that v3-4-test is built regularly,  
>>> this
>>> doesn't mean v3-3-test is ready to be removed from the build farm.
>>> While it doesn't probably make sense to have a build farm target for
>>> every branch in git, there is a lot to be gained from regularly
>>> building and testing the branches that are under active development,
>>> and that are soon to be released.
>>>
>>> I propose that we rename:
>>> samba_3_X_devel -> samba_3_master
>>> samba_3_X_test -> samba_3_3_test
>>>
>>> And add:
>>> samba_3_4_test
>>
>> While I agree with the rename, I do think it is a problem having so  
>> many
>> different Samba branches building.  It does pose a rather large load
>> (disk space and build space when there is churn) on the build farm
>> machines.
>
> I used the generic names, because it makes it much easier to switch
> between the branches. It's just a matter of a git checkout -b branch
> origin/branch and changing 2 variables in the build-farm svn repo.
>
> With the explicit names: we need to setup the new repo in the
> ftp/unpacked area, change the script that autogenerates configure.
> change a lot more places in the build-farm svn repo and add special
> hooks to delete the old directories. And maybe some more tricky  
> details
> I can't remember right now.
>
> For me the switch from v3-2-test to v3-3-test took 5 mins.
> While the switches before (without the generic names) took up to 3  
> hours
> and then carefully watching the build logs for the next 24 hours.
>
> I think it's easier to just display the mapping of the generic names  
> in
> the web interface and the notify mails to avoid the confusion, but
> keep generic names, as it's much easier to maintain.
>
> 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.

-Tim