You are viewing a plain text version of this content. The canonical link for it is here.
Posted to commits@commons.apache.org by er...@apache.org on 2016/05/31 01:37:01 UTC
[math] Reverting changes on "master" as per Commons Math policy.
Repository: commons-math
Updated Branches:
refs/heads/master ffc1caada -> 598edc127
Reverting changes on "master" as per Commons Math policy.
The corresponding changes have been ported into branch "develop".
Project: http://git-wip-us.apache.org/repos/asf/commons-math/repo
Commit: http://git-wip-us.apache.org/repos/asf/commons-math/commit/598edc12
Tree: http://git-wip-us.apache.org/repos/asf/commons-math/tree/598edc12
Diff: http://git-wip-us.apache.org/repos/asf/commons-math/diff/598edc12
Branch: refs/heads/master
Commit: 598edc12736945d27fb7dbd77cb81ac8e51f491a
Parents: ffc1caa
Author: Gilles <gi...@harfang.homelinux.org>
Authored: Tue May 31 03:20:13 2016 +0200
Committer: Gilles <gi...@harfang.homelinux.org>
Committed: Tue May 31 03:20:13 2016 +0200
----------------------------------------------------------------------
.../distribution/AbstractIntegerDistribution.java | 3 ++-
.../descriptive/MultivariateSummaryStatistics.java | 6 +++---
.../math4/stat/interval/ClopperPearsonInterval.java | 16 ++++++++--------
3 files changed, 13 insertions(+), 12 deletions(-)
----------------------------------------------------------------------
http://git-wip-us.apache.org/repos/asf/commons-math/blob/598edc12/src/main/java/org/apache/commons/math4/distribution/AbstractIntegerDistribution.java
----------------------------------------------------------------------
diff --git a/src/main/java/org/apache/commons/math4/distribution/AbstractIntegerDistribution.java b/src/main/java/org/apache/commons/math4/distribution/AbstractIntegerDistribution.java
index 4c42c01..95d6f07 100644
--- a/src/main/java/org/apache/commons/math4/distribution/AbstractIntegerDistribution.java
+++ b/src/main/java/org/apache/commons/math4/distribution/AbstractIntegerDistribution.java
@@ -209,7 +209,8 @@ public abstract class AbstractIntegerDistribution implements IntegerDistribution
*/
private double checkedCumulativeProbability(int argument)
throws MathInternalError {
- double result = cumulativeProbability(argument);
+ double result = Double.NaN;
+ result = cumulativeProbability(argument);
if (Double.isNaN(result)) {
throw new MathInternalError(LocalizedFormats
.DISCRETE_CUMULATIVE_PROBABILITY_RETURNED_NAN, argument);
http://git-wip-us.apache.org/repos/asf/commons-math/blob/598edc12/src/main/java/org/apache/commons/math4/stat/descriptive/MultivariateSummaryStatistics.java
----------------------------------------------------------------------
diff --git a/src/main/java/org/apache/commons/math4/stat/descriptive/MultivariateSummaryStatistics.java b/src/main/java/org/apache/commons/math4/stat/descriptive/MultivariateSummaryStatistics.java
index 39083d0..eb1642c 100644
--- a/src/main/java/org/apache/commons/math4/stat/descriptive/MultivariateSummaryStatistics.java
+++ b/src/main/java/org/apache/commons/math4/stat/descriptive/MultivariateSummaryStatistics.java
@@ -319,8 +319,8 @@ public class MultivariateSummaryStatistics
final String separator = ", ";
final String suffix = System.getProperty("line.separator");
StringBuilder outBuffer = new StringBuilder();
- outBuffer.append("MultivariateSummaryStatistics:").append(suffix);
- outBuffer.append("n: ").append(getN()).append(suffix);
+ outBuffer.append("MultivariateSummaryStatistics:" + suffix);
+ outBuffer.append("n: " + getN() + suffix);
append(outBuffer, getMin(), "min: ", separator, suffix);
append(outBuffer, getMax(), "max: ", separator, suffix);
append(outBuffer, getMean(), "mean: ", separator, suffix);
@@ -328,7 +328,7 @@ public class MultivariateSummaryStatistics
append(outBuffer, getSumSq(), "sum of squares: ", separator, suffix);
append(outBuffer, getSumLog(), "sum of logarithms: ", separator, suffix);
append(outBuffer, getStandardDeviation(), "standard deviation: ", separator, suffix);
- outBuffer.append("covariance: ").append(getCovariance()).append(suffix);
+ outBuffer.append("covariance: " + getCovariance().toString() + suffix);
return outBuffer.toString();
}
http://git-wip-us.apache.org/repos/asf/commons-math/blob/598edc12/src/main/java/org/apache/commons/math4/stat/interval/ClopperPearsonInterval.java
----------------------------------------------------------------------
diff --git a/src/main/java/org/apache/commons/math4/stat/interval/ClopperPearsonInterval.java b/src/main/java/org/apache/commons/math4/stat/interval/ClopperPearsonInterval.java
index ed0904c..bf5d6ad 100644
--- a/src/main/java/org/apache/commons/math4/stat/interval/ClopperPearsonInterval.java
+++ b/src/main/java/org/apache/commons/math4/stat/interval/ClopperPearsonInterval.java
@@ -35,19 +35,19 @@ public class ClopperPearsonInterval implements BinomialConfidenceInterval {
IntervalUtils.checkParameters(numberOfTrials, numberOfSuccesses, confidenceLevel);
double lowerBound = 0;
double upperBound = 0;
-
- if (numberOfSuccesses > 0) {
- final double alpha = (1.0 - confidenceLevel) / 2.0;
+ final double alpha = (1.0 - confidenceLevel) / 2.0;
- final FDistribution distributionLowerBound = new FDistribution(2 * (numberOfTrials - numberOfSuccesses + 1),
- 2 * numberOfSuccesses);
+ final FDistribution distributionLowerBound = new FDistribution(2 * (numberOfTrials - numberOfSuccesses + 1),
+ 2 * numberOfSuccesses);
+ if (numberOfSuccesses > 0) {
final double fValueLowerBound = distributionLowerBound.inverseCumulativeProbability(1 - alpha);
lowerBound = numberOfSuccesses /
(numberOfSuccesses + (numberOfTrials - numberOfSuccesses + 1) * fValueLowerBound);
+ }
-
- final FDistribution distributionUpperBound = new FDistribution(2 * (numberOfSuccesses + 1),
- 2 * (numberOfTrials - numberOfSuccesses));
+ final FDistribution distributionUpperBound = new FDistribution(2 * (numberOfSuccesses + 1),
+ 2 * (numberOfTrials - numberOfSuccesses));
+ if (numberOfSuccesses > 0) {
final double fValueUpperBound = distributionUpperBound.inverseCumulativeProbability(1 - alpha);
upperBound = (numberOfSuccesses + 1) * fValueUpperBound /
(numberOfTrials - numberOfSuccesses + (numberOfSuccesses + 1) * fValueUpperBound);
Re: [math] Repository Policy
Posted by 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
Posted by 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
Posted by 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
Re: [math] Repository Policy
Posted by 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 (was: Reverting changes on "master" as
per Commons Math policy)
Posted by Artem Barger <ar...@bargr.net>.
On Tue, May 31, 2016 at 5:43 PM, Rob Tompkins <ch...@gmail.com> wrote:
> On May 31, 2016, at 10:21 AM, Matt Sicker <bo...@gmail.com> wrote:
> >
> > Why not just rename master to something like stable, then rename develop
> to
> > master? Less confusing to people who don't know about git-flow.
>
> Generally when I think about an arbitrary github project I would think
> that the “master” branch reflects the latest released code, and the
> “develop” branch should reflect the inflight development. Assuming that the
> history of the branches is properly maintained, a topic branch based in
> master should be able to be worked on and then PR’d into develop (assuming
> that the individual doing the work has accommodated for the merge conflicts
> in migrating it to develop).
>
> If the project is mirrored in git, then I would argue that the semantics
> of the version control system should be used as opposed to using our own
> semantics because then the arbitrary developer coming from another git
> project can quickly figure out how to work with the codebase.
>
>
Well, IMO an average GutHub project usually uses a master branch as
ongoing branch for development and has "release" branch or even several
branches in case there are a couple of versions for release. Of course
working w/ feature branch for separate tasks merging/rebasing them later
into the master. But I think this is a matter of project policies and
agreements, important branches usually protected from accepting direct
commits into them.
BR,
- Artem.
Re: [math] Repository Policy (was: Reverting changes on "master" as per Commons Math policy)
Posted by Rob Tompkins <ch...@gmail.com>.
On May 31, 2016, at 10:21 AM, Matt Sicker <bo...@gmail.com> wrote:
>
> Why not just rename master to something like stable, then rename develop to
> master? Less confusing to people who don't know about git-flow.
Generally when I think about an arbitrary github project I would think that the “master” branch reflects the latest released code, and the “develop” branch should reflect the inflight development. Assuming that the history of the branches is properly maintained, a topic branch based in master should be able to be worked on and then PR’d into develop (assuming that the individual doing the work has accommodated for the merge conflicts in migrating it to develop).
If the project is mirrored in git, then I would argue that the semantics of the version control system should be used as opposed to using our own semantics because then the arbitrary developer coming from another git project can quickly figure out how to work with the codebase.
All the best,
-Rob
>
> On 31 May 2016 at 03:58, Gilles <gi...@harfang.homelinux.org> wrote:
>
>> On Tue, 31 May 2016 09:34:25 +0200, Emmanuel Bourg wrote:
>>
>>> Le 31/05/2016 à 03:37, erans@apache.org a écrit :
>>>
>>>> Repository: commons-math
>>>> Updated Branches:
>>>> refs/heads/master ffc1caada -> 598edc127
>>>>
>>>>
>>>> Reverting changes on "master" as per Commons Math policy.
>>>>
>>>> The corresponding changes have been ported into branch "develop".
>>>>
>>>
>>> Hi all,
>>>
>>> The repository policy for [math] is a bit confusing in my opinion.
>>>
>>
>> It causes confusion indeed but not because it is confusing.
>> Rather because of years of svn usage which git vows to change IIUC.
>>
>> People are used to work on the master/trunk branch,
>>>
>>
>> This is a wrong expectation for git workflow.
>> For anything (except perhaps trivial changes), people are expected
>> to work on a dedicated branch.
>> Cf. rationale in the document here:
>> http://nvie.com/posts/a-successful-git-branching-model/
>>
>> Discussion (and agreement) here:
>> http://markmail.org/message/7lnus64entdwj4vo
>>
>> and if we want to
>>> make the collaboration on our components as easy as possible I think we
>>> should stick to the common expectation. Otherwise contributors sending
>>> pull requests from GitHub are likely to base their work against the
>>> wrong branch, inducing extra work for the committers to rebase the
>>> changes against the real development trunk. Also I think it would be
>>> preferable for all Apache Commons components to follow the same
>>> repository layout.
>>>
>>> Having a stable branch isn't a bad idea (I've never felt the need for it
>>> on my projects though, and this adds some steps to the release process
>>> that we vowed to simplify), but this can be achieved with a separate
>>> 'releases' branch.
>>>
>>> So for Commons Math I'd suggest renaming the branches as follow:
>>> master -> releases (or just drop it)
>>> develop -> master
>>>
>>
>> I agree that a workflow that includes Github must be clarified.
>> An issue was opened:
>> https://issues.apache.org/jira/browse/MATH-1357
>>
>> Unfortunately I'm not familiar with Github in order to figure out
>> the right way to interface its expectations (e.g. Do all projects
>> exported to Github use only one branch?) with our new development
>> model (that requires creating a "feature branch" for each feature
>> rather than modify "master" or "develop" directly).
>>
>> This especially true for one-off contributors: we _don't_ want
>> "master" to be modified by code of yet unknown quality.
>>
>> Regards,
>> Gilles
>>
>>
>>
>>> Emmanuel Bourg
>>>
>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
>> For additional commands, e-mail: dev-help@commons.apache.org
>>
>>
>
>
> --
> Matt Sicker <bo...@gmail.com>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org
Re: [math] Repository Policy (was: Reverting changes on "master" as
per Commons Math policy)
Posted by Matt Sicker <bo...@gmail.com>.
Why not just rename master to something like stable, then rename develop to
master? Less confusing to people who don't know about git-flow.
On 31 May 2016 at 03:58, Gilles <gi...@harfang.homelinux.org> wrote:
> On Tue, 31 May 2016 09:34:25 +0200, Emmanuel Bourg wrote:
>
>> Le 31/05/2016 à 03:37, erans@apache.org a écrit :
>>
>>> Repository: commons-math
>>> Updated Branches:
>>> refs/heads/master ffc1caada -> 598edc127
>>>
>>>
>>> Reverting changes on "master" as per Commons Math policy.
>>>
>>> The corresponding changes have been ported into branch "develop".
>>>
>>
>> Hi all,
>>
>> The repository policy for [math] is a bit confusing in my opinion.
>>
>
> It causes confusion indeed but not because it is confusing.
> Rather because of years of svn usage which git vows to change IIUC.
>
> People are used to work on the master/trunk branch,
>>
>
> This is a wrong expectation for git workflow.
> For anything (except perhaps trivial changes), people are expected
> to work on a dedicated branch.
> Cf. rationale in the document here:
> http://nvie.com/posts/a-successful-git-branching-model/
>
> Discussion (and agreement) here:
> http://markmail.org/message/7lnus64entdwj4vo
>
> and if we want to
>> make the collaboration on our components as easy as possible I think we
>> should stick to the common expectation. Otherwise contributors sending
>> pull requests from GitHub are likely to base their work against the
>> wrong branch, inducing extra work for the committers to rebase the
>> changes against the real development trunk. Also I think it would be
>> preferable for all Apache Commons components to follow the same
>> repository layout.
>>
>> Having a stable branch isn't a bad idea (I've never felt the need for it
>> on my projects though, and this adds some steps to the release process
>> that we vowed to simplify), but this can be achieved with a separate
>> 'releases' branch.
>>
>> So for Commons Math I'd suggest renaming the branches as follow:
>> master -> releases (or just drop it)
>> develop -> master
>>
>
> I agree that a workflow that includes Github must be clarified.
> An issue was opened:
> https://issues.apache.org/jira/browse/MATH-1357
>
> Unfortunately I'm not familiar with Github in order to figure out
> the right way to interface its expectations (e.g. Do all projects
> exported to Github use only one branch?) with our new development
> model (that requires creating a "feature branch" for each feature
> rather than modify "master" or "develop" directly).
>
> This especially true for one-off contributors: we _don't_ want
> "master" to be modified by code of yet unknown quality.
>
> Regards,
> Gilles
>
>
>
>> Emmanuel Bourg
>>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
> For additional commands, e-mail: dev-help@commons.apache.org
>
>
--
Matt Sicker <bo...@gmail.com>
Re: [math] Repository Policy (was: Reverting changes on "master" as
per Commons Math policy)
Posted by Gilles <gi...@harfang.homelinux.org>.
On Tue, 31 May 2016 09:34:25 +0200, Emmanuel Bourg wrote:
> Le 31/05/2016 � 03:37, erans@apache.org a �crit :
>> Repository: commons-math
>> Updated Branches:
>> refs/heads/master ffc1caada -> 598edc127
>>
>>
>> Reverting changes on "master" as per Commons Math policy.
>>
>> The corresponding changes have been ported into branch "develop".
>
> Hi all,
>
> The repository policy for [math] is a bit confusing in my opinion.
It causes confusion indeed but not because it is confusing.
Rather because of years of svn usage which git vows to change IIUC.
> People are used to work on the master/trunk branch,
This is a wrong expectation for git workflow.
For anything (except perhaps trivial changes), people are expected
to work on a dedicated branch.
Cf. rationale in the document here:
http://nvie.com/posts/a-successful-git-branching-model/
Discussion (and agreement) here:
http://markmail.org/message/7lnus64entdwj4vo
> and if we want to
> make the collaboration on our components as easy as possible I think
> we
> should stick to the common expectation. Otherwise contributors
> sending
> pull requests from GitHub are likely to base their work against the
> wrong branch, inducing extra work for the committers to rebase the
> changes against the real development trunk. Also I think it would be
> preferable for all Apache Commons components to follow the same
> repository layout.
>
> Having a stable branch isn't a bad idea (I've never felt the need for
> it
> on my projects though, and this adds some steps to the release
> process
> that we vowed to simplify), but this can be achieved with a separate
> 'releases' branch.
>
> So for Commons Math I'd suggest renaming the branches as follow:
> master -> releases (or just drop it)
> develop -> master
I agree that a workflow that includes Github must be clarified.
An issue was opened:
https://issues.apache.org/jira/browse/MATH-1357
Unfortunately I'm not familiar with Github in order to figure out
the right way to interface its expectations (e.g. Do all projects
exported to Github use only one branch?) with our new development
model (that requires creating a "feature branch" for each feature
rather than modify "master" or "develop" directly).
This especially true for one-off contributors: we _don't_ want
"master" to be modified by code of yet unknown quality.
Regards,
Gilles
>
> 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 (was: Reverting changes on "master" as
per Commons Math policy)
Posted by Emmanuel Bourg <eb...@apache.org>.
Le 31/05/2016 03:37, erans@apache.org a crit :
> Repository: commons-math
> Updated Branches:
> refs/heads/master ffc1caada -> 598edc127
>
>
> Reverting changes on "master" as per Commons Math policy.
>
> The corresponding changes have been ported into branch "develop".
Hi all,
The repository policy for [math] is a bit confusing in my opinion.
People are used to work on the master/trunk branch, and if we want to
make the collaboration on our components as easy as possible I think we
should stick to the common expectation. Otherwise contributors sending
pull requests from GitHub are likely to base their work against the
wrong branch, inducing extra work for the committers to rebase the
changes against the real development trunk. Also I think it would be
preferable for all Apache Commons components to follow the same
repository layout.
Having a stable branch isn't a bad idea (I've never felt the need for it
on my projects though, and this adds some steps to the release process
that we vowed to simplify), but this can be achieved with a separate
'releases' branch.
So for Commons Math I'd suggest renaming the branches as follow:
master -> releases (or just drop it)
develop -> master
Emmanuel Bourg
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org