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

[Andrew Bartlett]

On Tue, 2009-03-24 at 08:17 +0100, Stefan (metze) Metzmacher wrote:
> 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 like it.  BTW, what is the difference between 3.4 and master at the
moment?

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

I mailed all the build farm owners, and nobody replied to say they would
have a problem with this.  

Please go ahead,

Andrew Bartlett

-- 
Andrew Bartlett
http://samba.org/~abartlet/
Authentication Developer, Samba Team           http://samba.org
Samba Developer, Red Hat Inc.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: This is a digitally signed message part
Url : http://lists.samba.org/archive/samba-technical/attachments/20090324/cd037bb3/attachment.bin