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

Stefan (metze) Metzmacher metze at samba.org
Tue Mar 24 07:17:53 GMT 2009


Tim Prouty schrieb:
> 
> 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.

would

samba_3_current => v3-3-test
samba_3_next    => v3-4-test
samba_3_master  => master

work for you?

I think we should just try to build all branches and then watch the farm
for a few days and disable samba_3_current on the boxes with low
diskspace, ok?

metze

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 252 bytes
Desc: OpenPGP digital signature
Url : http://lists.samba.org/archive/samba-technical/attachments/20090324/0f9097c1/signature.bin


More information about the samba-technical mailing list