Le 06/01/2016 15:19, Gilles a écrit :
> Hi.
Hi Gilles,
>
> 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.
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-unsubscr...@commons.apache.org
> For additional commands, e-mail: dev-h...@commons.apache.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
For additional commands, e-mail: dev-h...@commons.apache.org
