Why not just rename master to something like stable, then rename develop to master? Less confusing to people who don't know about git-flow.
On 31 May 2016 at 03:58, Gilles <gil...@harfang.homelinux.org> wrote: > On Tue, 31 May 2016 09:34:25 +0200, Emmanuel Bourg wrote: > >> Le 31/05/2016 à 03:37, er...@apache.org a écrit : >> >>> Repository: commons-math >>> Updated Branches: >>> refs/heads/master ffc1caada -> 598edc127 >>> >>> >>> Reverting changes on "master" as per Commons Math policy. >>> >>> The corresponding changes have been ported into branch "develop". >>> >> >> Hi all, >> >> The repository policy for [math] is a bit confusing in my opinion. >> > > It causes confusion indeed but not because it is confusing. > Rather because of years of svn usage which git vows to change IIUC. > > People are used to work on the master/trunk branch, >> > > This is a wrong expectation for git workflow. > For anything (except perhaps trivial changes), people are expected > to work on a dedicated branch. > Cf. rationale in the document here: > http://nvie.com/posts/a-successful-git-branching-model/ > > Discussion (and agreement) here: > http://markmail.org/message/7lnus64entdwj4vo > > and if we want to >> make the collaboration on our components as easy as possible I think we >> should stick to the common expectation. Otherwise contributors sending >> pull requests from GitHub are likely to base their work against the >> wrong branch, inducing extra work for the committers to rebase the >> changes against the real development trunk. Also I think it would be >> preferable for all Apache Commons components to follow the same >> repository layout. >> >> Having a stable branch isn't a bad idea (I've never felt the need for it >> on my projects though, and this adds some steps to the release process >> that we vowed to simplify), but this can be achieved with a separate >> 'releases' branch. >> >> So for Commons Math I'd suggest renaming the branches as follow: >> master -> releases (or just drop it) >> develop -> master >> > > I agree that a workflow that includes Github must be clarified. > An issue was opened: > https://issues.apache.org/jira/browse/MATH-1357 > > Unfortunately I'm not familiar with Github in order to figure out > the right way to interface its expectations (e.g. Do all projects > exported to Github use only one branch?) with our new development > model (that requires creating a "feature branch" for each feature > rather than modify "master" or "develop" directly). > > This especially true for one-off contributors: we _don't_ want > "master" to be modified by code of yet unknown quality. > > Regards, > Gilles > > > >> Emmanuel Bourg >> > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org > For additional commands, e-mail: dev-h...@commons.apache.org > > -- Matt Sicker <boa...@gmail.com>
