Re: clear policy discussions

[David Kastrup]

Graham Percival <address@hidden> writes:

> On Tue, Jul 10, 2012 at 09:06:10PM +0200, David Kastrup wrote:
>> Graham Percival <address@hidden> writes:
>> 
>> > My personal opinion is that we should not discuss major policy
>> > changes in the middle of a thread about dots and staff sizes.
>> 
>> It was in the course of changing the status to "Critical".
>
> That was not obvious to a casual reader.  If somebody only checked
> the lilypond mailing lists once a week, they'd have over 100
> emails to skim through, and I would delete the email thread called
> "issue 2648 repeat dots and staff sizes" without glancing at any
> message bodies.
>
>> > There is a proposal to change the stable release policy:
>> > http://lists.gnu.org/archive/html/lilypond-devel/2012-06/msg00462.html
>> > http://lilypond.org/~graham/gop/gop_3.html
>> >
>> > That proposal is currently "under debate", although there was such
>> > little discussion that I'm at a loss as to what to do next.
>> 
>> My personal beef with the proposal is that I just can't relate to it.
>> So I don't see myself as being able to make any worthwhile contribution.
>
> That itself is a valuable contribution!  If a proposal is so
> vague, or poorly worded, or just plain confusing

It is neither.

> that a main developer like you "can't relate to it", then there's no
> way that we should be adopting such a proposal.

The proposal addresses a problem space that I can't feel related to the
problems I am concerned with.

> At the very least the proposal should be rewritten; at most it should
> be scrapped outright.
>
>> The proposal is to make the definition of "critical regression" depend
>> on the regtests and double the size of the regtests in order to catch
>> the same amount of regressions.  It does not change the principal
>> problem: if we now discover bad recently introduced behavior, we have
>> the choice not to create a regression test for it (in which case the
>> release can go forward), or the release will get blocked again once the
>> test has been created.
>>
>> I think we can agree that refraining to create relevant regression
>> tests on purpose in order to make the release go forward would be
>> counterproductive.
>
> The proposal does not agree with you on that point.  The proposal
> is saying "let's not care about bad behaviour.  Let's only care
> about the functionality that is currently tested.  If there's some
> bad behaviour that's not covered by an existing regtest, we'll
> ignore that behaviour for the purpose of making a release".

The proposal also states that regtests should only be created once a
problem is fixed.

[...]

> Agreed stongly!  If you don't mind, I think I may copy&paste this
> verbatim into the "motivation" section of whatever revised
> proposal comes next.

No problem with that.

>> Policies should not turn good things into bad things.  So our knowledge
>> about regressions should be used for making a better qualified decision
>> when to release stable versions.  At the current point of time, it just
>> leads to the decision "no release".  A monkey could make such a
>> decision, and indeed, this has been a design goal of creating the
>> decision making procedures.
>
> That is absolutely true.  The goal was to have a crystal-clear
> process, and monkies are noted for their ability to observe solid
> materials whose molecules are arranged in an orderly, repeating
> pattern.
>
>> When we design our rules for dealing with facts, we have to take this
>> into account.  And that requires leeway for incorporating common sense.
>> The rule sets you write are based on "let's assume that we don't have a
>> release manager at our disposal with any amount of clue and good sense".
>
> "... and who doesn't know about lilypond internals + code, or
> documentation, or translations, or build process, etc".
>
>> I don't think that is a reasonable premise.  Not given the current
>> release managers.
>
> I disagree here.  There's a reason that I never review scheme
> patches, and only occasionally look at C++ patches where my only
> possible contribution is "hey, you didn't initialize this
> variable".

You are making the mistake of assuming that the release decisions are to
be based on personal code reviews.  We have an issue tracker and a
review system for giving a reasonable amount of information about the
current state of affairs.  If that is not sufficient, for example for
making a decision about whether to include a certain patch into the
stable release branch or not, you can ask developers how they feel about
including something.

You can make one heck of a better qualified decision than a monkey.
When you permit yourself to do so.

> I *don't* have any amount of clue when it comes to lilypond
> internals.  Is it safe to backport your latest fix to the parser?

So what?  Don't backport it then.  Check out the symptoms.  Say how much
of an annoyance they seem to you.  Ask whether developers consider a
backport reasonable.  Don't pretend that everyone disappeared until they
did.

> I have no clue; maybe that requires some other scheme internals
> change.  Maybe it doesn't.  I don't have the background to tell,
> nor am I sufficiently motivated to learn that background at the
> moment.

I would prefer solving real problems over panicking over hypothetical
ones.

> For better or worse, the current release manager *is* a trained
> monkey.

Monkeys can pick up clues from people.  Take a lesson from Hans, the
calculating horse.

> What about the next one?  Phil has been learning how to do it, and I
> certainly won't call *him* a trained monkey... but his expertise is
> documentation and build systems.

So you want to design a rule set that will let him do good work without
feedback?  Without consulting anybody?  Without trying to form a
judgment?  Do you really think that after all this time he can't do a
better job than a switchboard?

> That said, there is no reason why "the person who does a
> copy&paste from CG 11.2" has to be "the person who decides what
> gets backported" or even "the person who decides what version
> number to slap an a release".  It's beginning to look like we
> really *should* split up those roles.

No beef with that.  If you take a look at Linux development, you'll see
that every stable branch getting a different style of maintenance is
done by somebody different.

>> Other large projects try to evade personal responsibility by making
>> timed releases.  And guess what: even though their rule sets are as
>> rigid as our bug-based releases, when a real whopper turns up, they
>> disband their rule set temporarily, and take a week or even a month
>> longer.
>
> As an unimportant aside: really?  I can't recall Ubuntu or OpenBSD
> ever postponing a release.

Ubuntu 6.06 was two months behind schedule.  OpenBSD 4.6 was delayed one
month.

> Well, removing policies is also a policy.  Perhaps the best thing
> to do would be to adopt this policy for stable releases:
>
>     Person X will decide when to make a stable release.
> (the end)
>
> I'm certainly not opposed to such a policy!  I would want that
> policy to be clearly stated, discussed for any downsides (do we
> trust person X to be competent?  to have enough time?  maybe we
> should appoint person X for 6-month intervals?  or do it on a
> per-branch basis?  etc.).

It can also be "how to make a stable release".  This can turn into "ok,
I've decided to cherry-pick the following fixes, and barring any protest
until xxx, I will tag commit yyy as the stable release 2.16.0".  That
is, on the face of it, a policy.  But it is a policy made up based on
few weeks of lookahead rather than years.  And it allows for basing the
decision on judgment even at the last moment.

> If the final answer was "David Kastrup will have sole
> consideration for the 2.16.x releases (including when to make the
> release, what patches go into it (i.e. backports), etc); Phil
> Holmes will have sole consideration for the 2.17.x release; at the
> moment we will reserve judgement for any 2.18 or 3.0 releases",
> then I wouldn't object.

This kind of decision would seem to make good use of the current
resources; it would likely need adopting to the circumstances at some
point of time.  Nothing wrong with that.

> I agree that we're doing something wrong.  All I want to make sure
> that we have a clear and open discussion about how to fix it, so
> that no nobody (particularly "casual developers" who don't read
> the mailing list all the time) is unpleasantly surprised.

At the current point of time, I consider the unpleasant unsurprises a
more likely problem.

> I evidently wasn't clear in introducing GOP and their policies; a
> complete rejection of any proposal is certainly valid!  The GOP
> proposals are intended to begin debate, not end them.

What if they make one feel that one does not even know how to start?

-- 
David Kastrup