On May 31, 2016, at 10:21 AM, Matt Sicker <boa...@gmail.com> wrote: > > 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.
Generally when I think about an arbitrary github project I would think that the “master” branch reflects the latest released code, and the “develop” branch should reflect the inflight development. Assuming that the history of the branches is properly maintained, a topic branch based in master should be able to be worked on and then PR’d into develop (assuming that the individual doing the work has accommodated for the merge conflicts in migrating it to develop). If the project is mirrored in git, then I would argue that the semantics of the version control system should be used as opposed to using our own semantics because then the arbitrary developer coming from another git project can quickly figure out how to work with the codebase. All the best, -Rob > > 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> --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
