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
