Hi.
On Tue, 05 Jan 2016 21:47:52 -0000, l...@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-unsubscr...@commons.apache.org
For additional commands, e-mail: dev-h...@commons.apache.org
