On Wed, Jan 6, 2016 at 10:32 AM, Luc Maisonobe <l...@spaceroots.org> wrote:
> 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.
>
+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-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
>
>
