Motion: Sandbox Branches

[Stephen Woodbridge]

+1 for /sandbox branches. This is being used quite effectively in 
OpenLayers and other projects. I have also used these in other projects 
and they allow each developer to have areas oriented to specific 
projects and these can be created/merged and/or abandoned at will.

-Steve W


Howard Butler wrote:
> Daniel,
> 
> My major reason for a sandbox branch is similar to Frank's -- a vendor 
> branch that is a mix of backported 5.0 features on top of a 4.10 base.  
> I've made numerous additions and changes to the SDE driver that can't 
> make it into a 4.10 release, but 5.0's release is quite a ways out on 
> the horizon yet.
> 
> On May 17, 2007, at 1:59 PM, Daniel Morissette wrote:
>> Does the "." in "./sandbox" imply that anyone could create sandbox 
>> subdirectories anywhere?
>>
> 
> no.  That'd be really messy.
> 
>> Or instead was teh intention to create a global "/sandbox" besides 
>> branches and tags at the top level where developers could create their 
>> own development branches?
>>
> 
> yes
> 
>> I'd be okay with the creation of a global "/sandbox" area as an option 
>> for developers to create their own development branches if they like 
>> or need to do so.
>>
>> However I'm not keen on requiring that all new development take place 
>> in private branches to be merged later. I fear that the complexity and 
>> cost of merging changes in the end would outweigh any benefit. We 
>> haven't had too much problems with people breaking the trunk build in 
>> the past anyway. I fully agree with you that having most activity in 
>> trunk "makes people aware of the consequences of their actions on 
>> other folks and makes buildbot testing simple."
> 
> Given the limited discussion and somewhat indifference to the idea, I 
> move that we create /sandbox and allow developers to maintain private 
> branches at their discretion.
> 
> Howard