Re: [math] Repository Policy

[Emmanuel Bourg <eb...@apache.org>]

Le 31/05/2016 � 10:58, Gilles a �crit :

> It causes confusion indeed but not because it is confusing.
> Rather because of years of svn usage which git vows to change IIUC.

It's confusing because it's unexpected. If you look at the GitHub
projects the majority don't use this so called "git workflow" (that
should actually be named "Vincent Driessen's Git workflow", its name
make it sound like it's the one true way to use Git, but it isn't).

Using feature branches is fine, but I'd advocate merging to 'master'
instead of 'develop'. If you switch the branch names as I suggested you
can keep the same workflow *and* make it less confusing for newcomers.
Best of both worlds.

Emmanuel Bourg


---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org

Re: [math] Repository Policy

[Gilles <gi...@harfang.homelinux.org>]

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-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org

Re: [math] Repository Policy

[Emmanuel Bourg <eb...@apache.org>]

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.
- 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.
- 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).

Note that GitHub pull requests are implicitly feature branches, even if
they are committed on the master branch of the cloned repository. So my
view of what can be committed directly to the master branch really
applies to the Apache Commons committers.


> 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.


> 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.


> 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, I was just reacting to the commit reversal.

Emmanuel Bourg


---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org

Re: [math] Repository Policy

[Gilles <gi...@harfang.homelinux.org>]

On Tue, 31 May 2016 11:33:19 +0200, Emmanuel Bourg wrote:
> Le 31/05/2016 � 10:58, Gilles a �crit :
>
>> It causes confusion indeed but not because it is confusing.
>> Rather because of years of svn usage which git vows to change IIUC.
>
> It's confusing because it's unexpected. If you look at the GitHub
> projects the majority don't use this so called "git workflow" (that
> should actually be named "Vincent Driessen's Git workflow", its name
> make it sound like it's the one true way to use Git, but it isn't).

I pointed to the reference of the discussion that took place on
this very ML.

It didn't take into account what people do on Github, because nobody
raised it.

> Using feature branches is fine, but I'd advocate merging to 'master'
> instead of 'develop'. If you switch the branch names as I suggested 
> you
> can keep the same workflow *and* make it less confusing for 
> newcomers.
> Best of both worlds.

Are you positive that people will not continue updating "master"?

That is the key point, and not that the official (reviewed/accepted
by a committer) code is in a branch named "master" or "develop".

The nice thing with the current "Vincent Driessen's Git workflow" is
that it is _documented_.  Once people are informed how to 
contribute[1],
it is not a minor detail to be able to point them to a simple,
self-contained description of a way to use git, rather than having
to figure it out by themselves.

Or are we going to assume that all future contributors will come
through Github?  That would change the perspective, I agree.
But it would require to subsume more of our processes to the Github
workflow than just changing a name.
People (not me) advocated going in that direction, such as using
the Github forum tools rather than this ML to discuss issues.

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!]

Gilles

[1] As you pointed out, there isn't a single workflow that can be
     assumed for every project.
     I proposed to select one where there were several, making it
     confusing to argue with newcomers as to what to do.

>
> Emmanuel Bourg
>


---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org