Re: [Math] Next version(s)? (Was: [...] Putting MATH_3_X branch to post-release state.)

[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