commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Gilles <gil...@harfang.homelinux.org>
Subject Re: [Math] Next version(s)? (Was: [...] Putting MATH_3_X branch to post-release state.)
Date Wed, 06 Jan 2016 18:07:16 GMT
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


Mime
View raw message