You are viewing a plain text version of this content. The canonical link for it is here.
Posted to commits@commons.apache.org by lu...@apache.org on 2016/01/05 22:47:52 UTC
[7/7] [math] Putting MATH_3_X branch to post-release state.
Putting MATH_3_X branch to post-release state.
This change is only done in case a new release should be done.
This is however not really expected now and the next release should
rather be 4.0 than 3.7.
Project: http://git-wip-us.apache.org/repos/asf/commons-math/repo
Commit: http://git-wip-us.apache.org/repos/asf/commons-math/commit/838788fd
Tree: http://git-wip-us.apache.org/repos/asf/commons-math/tree/838788fd
Diff: http://git-wip-us.apache.org/repos/asf/commons-math/diff/838788fd
Branch: refs/heads/MATH_3_X
Commit: 838788fd6302d6cc91e1743144e0f14b71e4812e
Parents: 95a9d35
Author: Luc Maisonobe <lu...@apache.org>
Authored: Tue Jan 5 22:46:13 2016 +0100
Committer: Luc Maisonobe <lu...@apache.org>
Committed: Tue Jan 5 22:46:13 2016 +0100
----------------------------------------------------------------------
doap_math.rdf | 5 +++++
pom.xml | 2 +-
src/changes/changes.xml | 2 ++
3 files changed, 8 insertions(+), 1 deletion(-)
----------------------------------------------------------------------
http://git-wip-us.apache.org/repos/asf/commons-math/blob/838788fd/doap_math.rdf
----------------------------------------------------------------------
diff --git a/doap_math.rdf b/doap_math.rdf
index a728234..077eb81 100644
--- a/doap_math.rdf
+++ b/doap_math.rdf
@@ -38,6 +38,11 @@
<release>
<Version>
<name>commons-math</name>
+ <created>2016-01-05</created>
+ <revision>3.6</revision>
+ </Version>
+ <Version>
+ <name>commons-math</name>
<created>2015-04-17</created>
<revision>3.5</revision>
</Version>
http://git-wip-us.apache.org/repos/asf/commons-math/blob/838788fd/pom.xml
----------------------------------------------------------------------
diff --git a/pom.xml b/pom.xml
index 3705a86..4153bff 100644
--- a/pom.xml
+++ b/pom.xml
@@ -24,7 +24,7 @@
<modelVersion>4.0.0</modelVersion>
<groupId>org.apache.commons</groupId>
<artifactId>commons-math3</artifactId>
- <version>3.6</version>
+ <version>3.7-SNAPSHOT</version>
<name>Apache Commons Math</name>
<inceptionYear>2003</inceptionYear>
http://git-wip-us.apache.org/repos/asf/commons-math/blob/838788fd/src/changes/changes.xml
----------------------------------------------------------------------
diff --git a/src/changes/changes.xml b/src/changes/changes.xml
index 21ab68f..d9a8b46 100644
--- a/src/changes/changes.xml
+++ b/src/changes/changes.xml
@@ -50,6 +50,8 @@ If the output is not quite correct, check for invisible trailing spaces!
<title>Commons Math Release Notes</title>
</properties>
<body>
+ <release version="3.7" date="TBD" description="TBD">
+ </release>
<release version="3.6" date="2016-01-05" description="
This is a minor release: It combines bug fixes and new features.
Changes to existing features were made in a backwards-compatible
Re: [Math] Next version(s)? (Was: [...] Putting MATH_3_X branch to
post-release state.)
Posted by Phil Steitz <ph...@gmail.com>.
On Wed, Jan 6, 2016 at 10:32 AM, Luc Maisonobe <lu...@spaceroots.org> wrote:
> Le 06/01/2016 15:19, Gilles a écrit :
> > Hi.
>
> Hi Gilles,
>
> >
> > On Tue, 05 Jan 2016 21:47:52 -0000, luc@apache.org wrote:
> >> Putting MATH_3_X branch to post-release state.
> >>
> >> This change is only done in case a new release should be done.
> >> This is however not really expected now and the next release should
> >> rather be 4.0 than 3.7.
> >
> > The latest clash about changes in the "master" branch makes this
> > statement quite non obvious.
>
> I don't think anybody wants to keep 3.X indefinitely. We did start
> a 4.0 branch on master. The fact it doesn't progress fast doesn't
> mean people only want to continue on 3.X.
>
+1
I will likely continue to patch 3.x and even implement new features in that
branch that can be added compatibly. That does not mean I don't want to
see 4.0 stabilize and get released. We have a lot of users (yes, I am just
one of them, but I respectfully reserve the right to stand up for others
who do not participate here) on 3.x and at this point it is not clear how
much API breakage there is going to be in 4, so as long as it is easy to do
so, I plan to backport the patches I work on to 3.x.
>
> >
> > Can we, for once, have a real release policy put in place?
> > A policy that would be based on requirements transparently laid out?
> >
> > That would imply that a *zero* weight would be assigned to statements
> > made in order to represent an anonymous ("the users") group (that cannot
> > participate in the debate, as per "Your role at the ASF is one assigned
> > to you personally, [...]".)
> >
> > Of course, each developer is a user (*one* user).
> > Of course, each developer is entitled to his own idea of what CM is,
> > should be, or should not be (and the consequence thereof on the
> > project's management); but that should be clearly spelled out as one
> > opinion, on a par with any other developer's opinion.
>
> What I wrote or commit is only one people writings or work and was never
> stated as an overall meta opinion. When I speak about users, I speak
> about the users I know of, which are mainly my coworkers. Count it
> as one opinion only if you want and associate it to me only if you
> want. It is not intended to be considered as more or less important
> than others opinions. Putting zero weight to it arbitrarily is not
> better than putting a 10x weight on it.
>
> >
> > A useful policy will help in avoiding that high level questions
> > (such as "Backwards-compatibility or not?") constantly pollute
> > development issues (such as "Refactor <this code>").
> >
> > The policy should also include a plan for releases, so that we don't
> > have to wait until Luc needs one in a hurry, in order to prepare the
> > next release.
>
> We never waited until I need it. Anybody can perform release. Any
> contributor can ask for a release. I happened for other commons
> sub-project, and sometimes was done, sometimes not. The main
> point was always: is there someone available that volunteers to
> take the pain of the release. Each time I asked for a release, I
> do volunteer to do it. Here again, it could have been anybody instead
> of me.
>
> We all want to Release Early Release Often, and we all fail to do it
> because sincerely, it is a pain. So we end up doing release irregularly.
>
> We are not in a corporate environment when a manager can dictate rules
> that must be obeyed. This is a voluntary-based project. So even if we
> were to decide some fixed rules, with high level requirement or fixed
> release plans, we would never follow these plans in reality. We already
> said quite a number of times: we should release more often. We never
> succeeded to do it effectively.
>
+1
Your great work documenting the release process is a big help. The way it
has always worked in Commons is someone proposes to make a release,
presents a plan, volunteers to do it, and cuts the release. Yes, it is a
lot of work. Yes, we don't do it enough. But the challenge is almost
never agreeing on release contents. Sometimes our desires are bigger than
our ability to get things done in the scope of a single release and it ends
up taking us a long time; but I don't think the answer is to impose a
schedule or add more rules. Good automation and keeping code close to
"releasable" on our main lines is the best thing we can do, IMO. The
branching model discussed else-thread should help with the second of these.
>
> >
> > Most importantly, we must know what are the requirements in order to
> > start to manage this project in any sensible way.
> > In particular, a policy should prevent to informally come back on
> > previous formal decisions, with its trail of "draining" discussions.
>
> So we should have minutes of decisions, with a signature of all
> participants, and some regular meetings to monitor progress. And what
> about a penalty if we don't meet deadline? Oh, and of course we should
> nominate a manager, and have an independent quality management to
> oversee what we do and check we really stick to the rules. We should
> probably write some specification documents, and interface control
> documents, and preliminary design documents, detailed design also,
> and probably some test plans and development guidelines ... and we
> should get paid.
>
> Of course I go to the extreme here, and the paragraph above is
> expected to be read as humorous. What I want to point out is
> that in a community and collaborative development (yes, I really
> mean it *is* collaborative and we succeed in it), rules are fuzzy,
> and followed if they are natural enough that they are not really
> rules.
>
I will again quote gstein (who does not remember saying exactly this),
"rules that people follow are needless; rules that people don't follow
don't work"
I expect your TPS report tomorrow AM, Luc :)
Phil
>
> >
> > Do the above points seem a common starting ground?
>
> As long as these are fuzzy rules, yes. If they are strong policy
> in a corporate-like management, no.
>
> >
> > If so, we can begin to list the issues which the policy should aim
> > at answering.
> > I'd start with the following:
> > * Release early, release often (and what it means, in practice,
> > for CM)
>
> Big +1. Hey, we already want that. It is just that saying it
> won't make it appear magically. Someone has to take the pain.
>
> > * Several development targets or a single one? [Depends on which
> > are the "requirements".]
>
> I don't understand what you mean here.
>
> >
> > To make things clearer, we could first work on a template of questions
> > whose answers would help in defining the various directions which the
> > CM developers are interested in. And then we'll have to decide which
> > project direction(s) the PMC wants to and/or is able to handle.
> >
> > No policy (or several "personal" policies, a.k.a. hidden agenda) is
> > what _really_ drains this "community".
>
> Strong policy (or inflexible policy, a.k.a. corporate management) is
> what would explode this community.
>
> best regards,
> Luc
>
> >
> >
> > Regards,
> > Gilles
> >
> >> [...]
> >
> >
> > ---------------------------------------------------------------------
> > 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
>
>
Re: [Math] Next version(s)? (Was: [...] Putting MATH_3_X branch to post-release state.)
Posted by Phil Steitz <ph...@gmail.com>.
> On Wed, Jan 6, 2016 at 11:07 AM, Gilles <gi...@harfang.homelinux.org> wrote:
> Hi Luc.
>
>> On Wed, 6 Jan 2016 18:32:37 +0100, Luc Maisonobe wrote:
>> Le 06/01/2016 15:19, Gilles a écrit :
>>> Hi.
>>
>> Hi Gilles,
>>
>>>
>>>> On Tue, 05 Jan 2016 21:47:52 -0000, luc@apache.org wrote:
>>>> Putting MATH_3_X branch to post-release state.
>>>>
>>>> This change is only done in case a new release should be done.
>>>> This is however not really expected now and the next release should
>>>> rather be 4.0 than 3.7.
>>>
>>> The latest clash about changes in the "master" branch makes this
>>> statement quite non obvious.
>>
>> I don't think anybody wants to keep 3.X indefinitely. We did start
>> a 4.0 branch on master. The fact it doesn't progress fast doesn't
>> mean people only want to continue on 3.X.
>>
>>>
>>> Can we, for once, have a real release policy put in place?
>>> A policy that would be based on requirements transparently laid out?
>>>
>>> That would imply that a *zero* weight would be assigned to statements
>>> made in order to represent an anonymous ("the users") group (that cannot
>>> participate in the debate, as per "Your role at the ASF is one assigned
>>> to you personally, [...]".)
>>>
>>> Of course, each developer is a user (*one* user).
>>> Of course, each developer is entitled to his own idea of what CM is,
>>> should be, or should not be (and the consequence thereof on the
>>> project's management); but that should be clearly spelled out as one
>>> opinion, on a par with any other developer's opinion.
>>
>> What I wrote or commit is only one people writings or work and was never
>> stated as an overall meta opinion. When I speak about users, I speak
>> about the users I know of, which are mainly my coworkers. Count it
>> as one opinion only if you want and associate it to me only if you
>> want. It is not intended to be considered as more or less important
>> than others opinions. Putting zero weight to it arbitrarily is not
>> better than putting a 10x weight on it.
>
> I meant that a statement like "I want this or that" gets weight one.
> A statement that says "The users want this or that" gets zero weight.
>
> So, yes, 1 + 0 = 1, if you like.
>
>>>
>>> A useful policy will help in avoiding that high level questions
>>> (such as "Backwards-compatibility or not?") constantly pollute
>>> development issues (such as "Refactor <this code>").
>>>
>>> The policy should also include a plan for releases, so that we don't
>>> have to wait until Luc needs one in a hurry, in order to prepare the
>>> next release.
>>
>> We never waited until I need it. Anybody can perform release. Any
>> contributor can ask for a release. I happened for other commons
>> sub-project, and sometimes was done, sometimes not. The main
>> point was always: is there someone available that volunteers to
>> take the pain of the release. Each time I asked for a release, I
>> do volunteer to do it. Here again, it could have been anybody instead
>> of me.
>
> You got what I meant in reverse: it is fortunate that you need a release
> once in a while because otherwise, there would be none.
>
> What I propose is that we decide to release more often and prepare the
> release at the deadline (unless there was no development of course).
>
>>
>> We all want to Release Early Release Often, and we all fail to do it
>> because sincerely, it is a pain. So we end up doing release irregularly.
>>
>> We are not in a corporate environment when a manager can dictate rules
>> that must be obeyed. This is a voluntary-based project. So even if we
>> were to decide some fixed rules, with high level requirement or fixed
>> release plans, we would never follow these plans in reality. We already
>> said quite a number of times: we should release more often. We never
>> succeeded to do it effectively.
>>
>>>
>>> Most importantly, we must know what are the requirements in order to
>>> start to manage this project in any sensible way.
>>> In particular, a policy should prevent to informally come back on
>>> previous formal decisions, with its trail of "draining" discussions.
>>
>> So we should have minutes of decisions, with a signature of all
>> participants, and some regular meetings to monitor progress. And what
>> about a penalty if we don't meet deadline? Oh, and of course we should
>> nominate a manager, and have an independent quality management to
>> oversee what we do and check we really stick to the rules. We should
>> probably write some specification documents, and interface control
>> documents, and preliminary design documents, detailed design also,
>> and probably some test plans and development guidelines ... and we
>> should get paid.
>>
>> Of course I go to the extreme here, and the paragraph above is
>> expected to be read as humorous. What I want to point out is
>> that in a community and collaborative development (yes, I really
>> mean it *is* collaborative and we succeed in it), rules are fuzzy,
>> and followed if they are natural enough that they are not really
>> rules.
>>
>>>
>>> Do the above points seem a common starting ground?
>>
>> As long as these are fuzzy rules, yes. If they are strong policy
>> in a corporate-like management, no.
>>
>>>
>>> If so, we can begin to list the issues which the policy should aim
>>> at answering.
>>> I'd start with the following:
>>> * Release early, release often (and what it means, in practice,
>>> for CM)
>>
>> Big +1. Hey, we already want that. It is just that saying it
>> won't make it appear magically. Someone has to take the pain.
>>
>>> * Several development targets or a single one? [Depends on which
>>> are the "requirements".]
>>
>> I don't understand what you mean here.
>
> One possibility is to want to keep both
> * a long-term compatible line of development (or just bug-fix), and
> * a cutting-edge line of development
>
> To be clear:
> In the first line, we can keep all the cruft and Java 5...
> In the second line, we do current Java programming and break everything
> as often as we fancy. ;-)
>
> There can be additional middle-ground lines with adapter layers.
>
>>>
>>> To make things clearer, we could first work on a template of questions
>>> whose answers would help in defining the various directions which the
>>> CM developers are interested in. And then we'll have to decide which
>>> project direction(s) the PMC wants to and/or is able to handle.
>>>
>>> No policy (or several "personal" policies, a.k.a. hidden agenda) is
>>> what _really_ drains this "community".
>>
>> Strong policy (or inflexible policy, a.k.a. corporate management) is
>> what would explode this community.
>
> I don't see it as viable that the unnamed policy in force is compatibility
> (far, far, far) above all else.
>
> Regards,
> Gilles
>
>>
>>
>> best regards,
>> Luc
>>
>>>
>>>
>>> Regards,
>>> Gilles
>>>
>>>> [...]
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
> For additional commands, e-mail: dev-help@commons.apache.org
Re: [Math] Next version(s)? (Was: [...] Putting MATH_3_X branch to post-release state.)
Posted by Gilles <gi...@harfang.homelinux.org>.
Hi Luc.
On Wed, 6 Jan 2016 18:32:37 +0100, Luc Maisonobe wrote:
> Le 06/01/2016 15:19, Gilles a écrit :
>> Hi.
>
> Hi Gilles,
>
>>
>> On Tue, 05 Jan 2016 21:47:52 -0000, luc@apache.org wrote:
>>> Putting MATH_3_X branch to post-release state.
>>>
>>> This change is only done in case a new release should be done.
>>> This is however not really expected now and the next release should
>>> rather be 4.0 than 3.7.
>>
>> The latest clash about changes in the "master" branch makes this
>> statement quite non obvious.
>
> I don't think anybody wants to keep 3.X indefinitely. We did start
> a 4.0 branch on master. The fact it doesn't progress fast doesn't
> mean people only want to continue on 3.X.
>
>>
>> Can we, for once, have a real release policy put in place?
>> A policy that would be based on requirements transparently laid out?
>>
>> That would imply that a *zero* weight would be assigned to
>> statements
>> made in order to represent an anonymous ("the users") group (that
>> cannot
>> participate in the debate, as per "Your role at the ASF is one
>> assigned
>> to you personally, [...]".)
>>
>> Of course, each developer is a user (*one* user).
>> Of course, each developer is entitled to his own idea of what CM is,
>> should be, or should not be (and the consequence thereof on the
>> project's management); but that should be clearly spelled out as one
>> opinion, on a par with any other developer's opinion.
>
> What I wrote or commit is only one people writings or work and was
> never
> stated as an overall meta opinion. When I speak about users, I speak
> about the users I know of, which are mainly my coworkers. Count it
> as one opinion only if you want and associate it to me only if you
> want. It is not intended to be considered as more or less important
> than others opinions. Putting zero weight to it arbitrarily is not
> better than putting a 10x weight on it.
I meant that a statement like "I want this or that" gets weight one.
A statement that says "The users want this or that" gets zero weight.
So, yes, 1 + 0 = 1, if you like.
>>
>> A useful policy will help in avoiding that high level questions
>> (such as "Backwards-compatibility or not?") constantly pollute
>> development issues (such as "Refactor <this code>").
>>
>> The policy should also include a plan for releases, so that we don't
>> have to wait until Luc needs one in a hurry, in order to prepare the
>> next release.
>
> We never waited until I need it. Anybody can perform release. Any
> contributor can ask for a release. I happened for other commons
> sub-project, and sometimes was done, sometimes not. The main
> point was always: is there someone available that volunteers to
> take the pain of the release. Each time I asked for a release, I
> do volunteer to do it. Here again, it could have been anybody instead
> of me.
You got what I meant in reverse: it is fortunate that you need a
release
once in a while because otherwise, there would be none.
What I propose is that we decide to release more often and prepare the
release at the deadline (unless there was no development of course).
>
> We all want to Release Early Release Often, and we all fail to do it
> because sincerely, it is a pain. So we end up doing release
> irregularly.
>
> We are not in a corporate environment when a manager can dictate
> rules
> that must be obeyed. This is a voluntary-based project. So even if we
> were to decide some fixed rules, with high level requirement or fixed
> release plans, we would never follow these plans in reality. We
> already
> said quite a number of times: we should release more often. We never
> succeeded to do it effectively.
>
>>
>> Most importantly, we must know what are the requirements in order to
>> start to manage this project in any sensible way.
>> In particular, a policy should prevent to informally come back on
>> previous formal decisions, with its trail of "draining" discussions.
>
> So we should have minutes of decisions, with a signature of all
> participants, and some regular meetings to monitor progress. And what
> about a penalty if we don't meet deadline? Oh, and of course we
> should
> nominate a manager, and have an independent quality management to
> oversee what we do and check we really stick to the rules. We should
> probably write some specification documents, and interface control
> documents, and preliminary design documents, detailed design also,
> and probably some test plans and development guidelines ... and we
> should get paid.
>
> Of course I go to the extreme here, and the paragraph above is
> expected to be read as humorous. What I want to point out is
> that in a community and collaborative development (yes, I really
> mean it *is* collaborative and we succeed in it), rules are fuzzy,
> and followed if they are natural enough that they are not really
> rules.
>
>>
>> Do the above points seem a common starting ground?
>
> As long as these are fuzzy rules, yes. If they are strong policy
> in a corporate-like management, no.
>
>>
>> If so, we can begin to list the issues which the policy should aim
>> at answering.
>> I'd start with the following:
>> * Release early, release often (and what it means, in practice,
>> for CM)
>
> Big +1. Hey, we already want that. It is just that saying it
> won't make it appear magically. Someone has to take the pain.
>
>> * Several development targets or a single one? [Depends on which
>> are the "requirements".]
>
> I don't understand what you mean here.
One possibility is to want to keep both
* a long-term compatible line of development (or just bug-fix), and
* a cutting-edge line of development
To be clear:
In the first line, we can keep all the cruft and Java 5...
In the second line, we do current Java programming and break everything
as often as we fancy. ;-)
There can be additional middle-ground lines with adapter layers.
>>
>> To make things clearer, we could first work on a template of
>> questions
>> whose answers would help in defining the various directions which
>> the
>> CM developers are interested in. And then we'll have to decide
>> which
>> project direction(s) the PMC wants to and/or is able to handle.
>>
>> No policy (or several "personal" policies, a.k.a. hidden agenda) is
>> what _really_ drains this "community".
>
> Strong policy (or inflexible policy, a.k.a. corporate management) is
> what would explode this community.
I don't see it as viable that the unnamed policy in force is
compatibility
(far, far, far) above all else.
Regards,
Gilles
>
>
> best regards,
> Luc
>
>>
>>
>> Regards,
>> Gilles
>>
>>> [...]
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org
Re: [Math] Next version(s)? (Was: [...] Putting MATH_3_X branch to
post-release state.)
Posted by Luc Maisonobe <lu...@spaceroots.org>.
Le 06/01/2016 15:19, Gilles a écrit :
> Hi.
Hi Gilles,
>
> On Tue, 05 Jan 2016 21:47:52 -0000, luc@apache.org wrote:
>> Putting MATH_3_X branch to post-release state.
>>
>> This change is only done in case a new release should be done.
>> This is however not really expected now and the next release should
>> rather be 4.0 than 3.7.
>
> The latest clash about changes in the "master" branch makes this
> statement quite non obvious.
I don't think anybody wants to keep 3.X indefinitely. We did start
a 4.0 branch on master. The fact it doesn't progress fast doesn't
mean people only want to continue on 3.X.
>
> Can we, for once, have a real release policy put in place?
> A policy that would be based on requirements transparently laid out?
>
> That would imply that a *zero* weight would be assigned to statements
> made in order to represent an anonymous ("the users") group (that cannot
> participate in the debate, as per "Your role at the ASF is one assigned
> to you personally, [...]".)
>
> Of course, each developer is a user (*one* user).
> Of course, each developer is entitled to his own idea of what CM is,
> should be, or should not be (and the consequence thereof on the
> project's management); but that should be clearly spelled out as one
> opinion, on a par with any other developer's opinion.
What I wrote or commit is only one people writings or work and was never
stated as an overall meta opinion. When I speak about users, I speak
about the users I know of, which are mainly my coworkers. Count it
as one opinion only if you want and associate it to me only if you
want. It is not intended to be considered as more or less important
than others opinions. Putting zero weight to it arbitrarily is not
better than putting a 10x weight on it.
>
> A useful policy will help in avoiding that high level questions
> (such as "Backwards-compatibility or not?") constantly pollute
> development issues (such as "Refactor <this code>").
>
> The policy should also include a plan for releases, so that we don't
> have to wait until Luc needs one in a hurry, in order to prepare the
> next release.
We never waited until I need it. Anybody can perform release. Any
contributor can ask for a release. I happened for other commons
sub-project, and sometimes was done, sometimes not. The main
point was always: is there someone available that volunteers to
take the pain of the release. Each time I asked for a release, I
do volunteer to do it. Here again, it could have been anybody instead
of me.
We all want to Release Early Release Often, and we all fail to do it
because sincerely, it is a pain. So we end up doing release irregularly.
We are not in a corporate environment when a manager can dictate rules
that must be obeyed. This is a voluntary-based project. So even if we
were to decide some fixed rules, with high level requirement or fixed
release plans, we would never follow these plans in reality. We already
said quite a number of times: we should release more often. We never
succeeded to do it effectively.
>
> Most importantly, we must know what are the requirements in order to
> start to manage this project in any sensible way.
> In particular, a policy should prevent to informally come back on
> previous formal decisions, with its trail of "draining" discussions.
So we should have minutes of decisions, with a signature of all
participants, and some regular meetings to monitor progress. And what
about a penalty if we don't meet deadline? Oh, and of course we should
nominate a manager, and have an independent quality management to
oversee what we do and check we really stick to the rules. We should
probably write some specification documents, and interface control
documents, and preliminary design documents, detailed design also,
and probably some test plans and development guidelines ... and we
should get paid.
Of course I go to the extreme here, and the paragraph above is
expected to be read as humorous. What I want to point out is
that in a community and collaborative development (yes, I really
mean it *is* collaborative and we succeed in it), rules are fuzzy,
and followed if they are natural enough that they are not really
rules.
>
> Do the above points seem a common starting ground?
As long as these are fuzzy rules, yes. If they are strong policy
in a corporate-like management, no.
>
> If so, we can begin to list the issues which the policy should aim
> at answering.
> I'd start with the following:
> * Release early, release often (and what it means, in practice,
> for CM)
Big +1. Hey, we already want that. It is just that saying it
won't make it appear magically. Someone has to take the pain.
> * Several development targets or a single one? [Depends on which
> are the "requirements".]
I don't understand what you mean here.
>
> To make things clearer, we could first work on a template of questions
> whose answers would help in defining the various directions which the
> CM developers are interested in. And then we'll have to decide which
> project direction(s) the PMC wants to and/or is able to handle.
>
> No policy (or several "personal" policies, a.k.a. hidden agenda) is
> what _really_ drains this "community".
Strong policy (or inflexible policy, a.k.a. corporate management) is
what would explode this community.
best regards,
Luc
>
>
> Regards,
> Gilles
>
>> [...]
>
>
> ---------------------------------------------------------------------
> 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
[Math] Next version(s)? (Was: [...] Putting MATH_3_X branch to post-release state.)
Posted by Gilles <gi...@harfang.homelinux.org>.
Hi.
On Tue, 05 Jan 2016 21:47:52 -0000, luc@apache.org wrote:
> Putting MATH_3_X branch to post-release state.
>
> This change is only done in case a new release should be done.
> This is however not really expected now and the next release should
> rather be 4.0 than 3.7.
The latest clash about changes in the "master" branch makes this
statement quite non obvious.
Can we, for once, have a real release policy put in place?
A policy that would be based on requirements transparently laid out?
That would imply that a *zero* weight would be assigned to statements
made in order to represent an anonymous ("the users") group (that
cannot
participate in the debate, as per "Your role at the ASF is one assigned
to you personally, [...]".)
Of course, each developer is a user (*one* user).
Of course, each developer is entitled to his own idea of what CM is,
should be, or should not be (and the consequence thereof on the
project's management); but that should be clearly spelled out as one
opinion, on a par with any other developer's opinion.
A useful policy will help in avoiding that high level questions
(such as "Backwards-compatibility or not?") constantly pollute
development issues (such as "Refactor <this code>").
The policy should also include a plan for releases, so that we don't
have to wait until Luc needs one in a hurry, in order to prepare the
next release.
Most importantly, we must know what are the requirements in order to
start to manage this project in any sensible way.
In particular, a policy should prevent to informally come back on
previous formal decisions, with its trail of "draining" discussions.
Do the above points seem a common starting ground?
If so, we can begin to list the issues which the policy should aim
at answering.
I'd start with the following:
* Release early, release often (and what it means, in practice,
for CM)
* Several development targets or a single one? [Depends on which
are the "requirements".]
To make things clearer, we could first work on a template of questions
whose answers would help in defining the various directions which the
CM developers are interested in. And then we'll have to decide which
project direction(s) the PMC wants to and/or is able to handle.
No policy (or several "personal" policies, a.k.a. hidden agenda) is
what _really_ drains this "community".
Regards,
Gilles
> [...]
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org