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

[Tim Prouty]

On Mar 15, 2009, at 6:51 PM, Andrew Bartlett wrote:

> 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.

Volker and Andrew, thank you for the feedback.

It should be be a top priority that we're regularly testing and
continually stabilizing code that is being released for users to
run in production environments.  The build farm is currently the
best way to ensure the quality of the code that is being shipped.
smbtorture and the other automated tests are absolutely excellent
resources, and we should be leveraging them in every way
possible.  With the price of disk space being incredibly low, it
would be a shame to let disk space stand in the way of fully
utilizing the sophisticated automation infrastructure that is
already in place.

I realize that some build machines are running legacy physical
hardware that may make it difficult to add additional disks.
Most of the build machines are running *nix flavors that could be
easily virtualized to run on a single phsical machine, with a
$100 1 TB hard drive providing the storage for all of the
machines.  Virtualizing the build farm is beyond the scope of
this discussion, but it's definitely something to think about
going forward.

At the very least a third samba 3 build farm branch target can be
added, and the build machines that don't have sufficient disk
space can choose to opt-out of building the third branch.  I can
work on coordinating the rename and the addition of the third
branch this week if there are no other concerns.

-Tim