commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Gilles <gil...@harfang.homelinux.org>
Subject Re: [math] Repository Policy
Date Tue, 31 May 2016 10:41:10 GMT
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


Mime
View raw message