Re: [math] Repository Policy

[Rob Tompkins <ch...@gmail.com>]

That seems reasonable based upon the other git based commons repos. 

-Rob

> On May 31, 2016, at 12:08 PM, Stian Soiland-Reyes <st...@apache.org> wrote:
> 
> To reduce complexity and confusion, I would generally hope for
> "master" to be where development happens, rather than an additional
> "develop" - as that means we now have three levels of "releases" to
> deal with:
> 
> * tagged/voted/published releases
> * a supposedly stable "master" that is somewhere between last release
> and develop, in a "releasable state"
> * a probably unstable "develop" which merges feature branches but
> might take lots of extra effort before it can be released
> 
> The problem is that people will still end up making feature branches
> and pull requests from "master"  - changing the default branch in
> GitHub does a lot to mitigate that, but perhaps better if we end up
> agreeing to this model for a component, then we can avoid "master"
> altogether and rather call it "stable"?
> 
> (Note: "master" is also special in git.apache.org as it does not allow
> removing commits)
> 
> 
>> On 31 May 2016 at 15:52, dbrosIus <db...@baybroadband.net> wrote:
>> Most servers allow you to specify a  default branch so that when you clone a repository you are on that branch.  I'm used to that from github, and didn't think twice about it,  which caused the last problem.  If this is possible here,  it would probably fix most cases.
>> 
>> -------- Original message --------
>> From: Gilles <gi...@harfang.homelinux.org>
>> Date: 05/31/2016  9:26 AM  (GMT-05:00)
>> To: dev@commons.apache.org
>> Subject: Re: [math] Repository Policy
>> 
>>> 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
> 
> 
> 
> -- 
> Stian Soiland-Reyes
> Apache Taverna (incubating), Apache Commons
> http://orcid.org/0000-0001-9842-9718
> 
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
> For additional commands, e-mail: dev-help@commons.apache.org
> 

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