On Tue, 31 May 2016 13:22:10 +0200, Emmanuel Bourg wrote:
Le 31/05/2016 à 12:41, Gilles a écrit :
Are you positive that people will not continue updating "master"?
Well that depends on the modification pushed:
- for trivial changes like updating the version of a maven plugin
there
is no point creating a feature branch, it can be committed directly
on
the trunk/master.
Generally yes.
But then mileage start to vary, as to what is trivial for one and
not so for another.
Hence I tend to limit "trivial" to Javadoc changes, unuse "import"
statements, or a commit that is required to fix a broken build.
For all the rest, I've been taught here (by you know who) that the
smaller the changeset the better.
- for simple fixes that don't change the API and come with a good
test
case, here again a direct commit on master is easier.
The point which people make about git is that it is no less easy
to create a temporary branch.
E.g. you pull code from an unknown person and run "mvn site" so
you can verify that CheckStyle and FindBugs are happy, and if
not you know that something must be fixed with that contribution;
but it does not prevent you to easily check that your own work
(in another branch then) is clean.
- for more complex changes involving design decisions, a feature
branch
is a good idea (unless a clear consensus was reached first on the
mailing list).
The devil is in the details. You shouldn't want to have non reviewed
code on the branch shared by everybody.
That's why I create remote feature branches and call for review
(through JIRA) in order to increase the likelihood that clean code
code is merge into the shared branch.
Note that GitHub pull requests are implicitly feature branches, even
if
they are committed on the master branch of the cloned repository.
I'm not following.
Sorry I have zero experience with Github.
So my
view of what can be committed directly to the master branch really
applies to the Apache Commons committers.
Then I don't understand; committers should know how to contribute...
We'll probably make mistakes (e.g. I committed some changes twice,
because of a "rebase" I think) but the excuse should not be that
on some other platform, they do it that way.
The problem I had with Eric (no offense ;-) is that some part of
the process for contributing through Github was not working.
[I still don't know what the problem was.]
Certainly it would help if that situation could be avoided in the
future.
Or are we going to assume that all future contributors will come
through Github? That would change the perspective, I agree.
GitHub has normalized the contribution process to open source
projects,
so I wouldn't be surprised if an increasing share of contributions
come
from GitHub in the future.
All the more then for a global solution (Commons level? Apache level?)
Currently, we are still wondering which component to migrate to
git and when to do it...
People (not me) advocated going in that direction, such as using
the Github forum tools rather than this ML to discuss issues.
I'm not advocating that though, and GitHub doesn't offer forums or
mailing lists anyway.
Again, I'm not a Github user, but I seem to recall that someone
mentioned how easier it was to collaborate on Github...
Singularly, I find this issue not the most urgent to deal with
as far as Commons Math is concerned!
[Especially when not only consensus was reached on this workflow
but unanimity!]
I agree this isn't urgent,
Thanks.
I was just reacting to the commit reversal.
As it happened, the additional burden was for me. But I'm OK to
do that (once in a while) in order to stick with a transparent
policy (and the same for everyone for a given component).
Even if an expert knows what he is doing, it is equally important
that non-experts and newcomers also understand what is happening
and even learn from it.
The Apache environment is not very successful at educating the
newcomers[1] despite the problem being known for a long time. :-(
Gilles
Emmanuel Bourg
[1] And that includes me who obviously (?) did not get it after 10
years.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
For additional commands, e-mail: dev-h...@commons.apache.org
