[Scons-dev] Branching/cloning policy

[Gary Oberbrunner]

On Thu, Aug 9, 2012 at 3:18 AM, Russel Winder <russel at winder.org.uk> wrote:

> Just wanting to get confirmation of the best way of working with the

> SCons repository to aid with pull requests.

>

> I had originally taken a clone and created a working branch on which to

> make my changes leaving default as a mirror of SCons. This would mean

> pull requests came from my long-lived branch. When pull requests were

> accepted the idea was to pull to default merge in my long-lived branch

> and then start new work on the same branch.  Was this too Git-ish a bit

> of thinking?

>

> I guess the alternative is to just have a complete separate repository

> as the D tool development one and to work only with its default, and to

> worry how to work with anonymous heads to handle things.

>

> What is come down to is which of

> http://mercurial.selenic.com/wiki/Workflows is

> http://www.scons.org/wiki/SconsMercurialWorkflows recommending for

> easiest use of BitBucket and pull requests such that reviews and

> feedback do not cause development freezes and/or chaos.


Hi Russel -- we haven't yet tried long-lived ongoing development on a
separate feature branch, but I see no reason that shouldn't work.  For
simple patches, most people are submitting on the default branch,
which is simplest for maintainers to merge.  I think you could work
either in a named branch, and submit pull requests from there (the
wiki has doc for how to merge those into the main repo), or in the
default branch of a separate scons-d repo and submit pull requests
from there.  Either one involves a merge on the maintainer's end.  I
don't think either one can cause a development freeze unless the patch
causes other outstanding patches to suddenly be un-mergeable (which I
hope will not happen).  On your end if you want to work in a
combination of those two ways (work on a branch and periodically merge
to default and submit pull requests from there) that's fine too; I
don't think the maintainer's job will be any different if you work
that way.

-- 
Gary