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 <dbros...@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 <gil...@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-unsubscr...@commons.apache.org >> For additional commands, e-mail: dev-h...@commons.apache.org > > > > -- > Stian Soiland-Reyes > Apache Taverna (incubating), Apache Commons > http://orcid.org/0000-0001-9842-9718 > > --------------------------------------------------------------------- > To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org > For additional commands, e-mail: dev-h...@commons.apache.org > --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
