Re: clear policy discussions

[David Kastrup]

Janek Warchoł <address@hidden> writes:

> On Fri, Jul 13, 2012 at 5:27 PM, David Kastrup <address@hidden> wrote:
>> Janek Warchoł <address@hidden> writes:
>>> Graham's focus is on transparent /rules/ that are easy to follow, and
>>> preferably won't lay *too* much responsibility on Release Manager's
>>> shoulders.
>>
>> To be exact: none.
>>
>>> And, above all, won't require the Release Manager to be an expert
>>> programmer.
>>
>> Or communicator.  Or look at recent issue reports more thoroughly than
>> counting "Critical" labels to get an impression of the state of affairs.
>> Or be possessed of common sense.  In fact, she could be a cron job if
>> somebody bothered putting the rules into a script.
>
> Oh, come on! :)
> Obviously, Graham would like to "dumb down" the rules as much as
> possible indeed (as long as he is the Release Manager it means less
> work for him).  But he didn't say that the rules *must* be 100%
> dumbed-down.  He actually expressed his willingness to accept the
> "person X decides when to make a release, period." policy which is a
> complete opposite of "dumbed down rules for a cronjob".
> I think that you exaggerated a bit.

No, I was commenting on our current policies.

>>> This is important, too, because Graham won't always be the Project
>>> Manager.  It's also not guaranteed that there'll always be an
>>> experienced developer with sufficient time to handle release tasks.
>>
>> I just don't buy the "experienced developer" thing.  Currently we let
>> our stable release process effectively be governed by randomness: we
>> are waiting for a large gap in the Poisson process detecting
>> regressions.  If we instead delegated that decision to a moron
>> without a clue, he would likely try to figure out from others what he
>> is supposed to do.
>
> I don't think so.  Morons don't know how to ask questions.

But they tend to go with the flow.

> But if you replace "moron" with "Janek", i'm sure he'd ask a lot of
> questions, and the result might be reasonable indeed! ;)
>
>> Which would be a large step forward in contrast to what we do now.
>>
>> In particular since it would make those others feel like they count,
>> do something for the success of the project, and are part of a team
>> turning out code, decisions, and releases.
>
> I see that you're angry with current system.

It is not a matter of angry.  It fails to do its job, and does it in a
manner that is damaging to the morale of the developers.

> I understand this, and i'd like to change the system to something
> better, too.
>
>> If a developer wants a release to happen now, what does he do?  His
>> best bet is to cease development, and cease using LilyPond to avoid
>> accidentally detecting a bug or regression.
>>
>> The only relevant way in which he can help with the release is to
>> give up on LilyPond, and that's what a number of developers have
>> already done.  The more developers are actively helping finding and
>> fixing problems and doing development, the less probable is it that
>> we will arrive at a stable release.
>
> What do you think about my revised proposal?  I think it addresses
> these issues.

I think we have arrived at a point where experimenting around with
decision-making systems does not make sense.

We have the basic problem that release-wrangling is a long procedure.
In the long run, it would be best to have a batch or script interface
that does the whole job.  While we don't have that, it would make sense
to split the jobs of release manager and release monkey which are now
combined.  It would be quite good if we had an automated release monkey
at some point of time, but in the mean time we should try getting about
three people who can do that, either because they have suitable hardware
themselves, or an account on such hardware.

Then we need release managers.  One for the developer releases.  They
decide when a release gets rolled.  The developer releases are not all
that important: avoid releasing recently introduced instabilities, avoid
releases that don't work, make for reasonable time frames.  One for the
upcoming stable branch, one for backports to the last stable branch.

Stable release timing should be such that we don't need more than two
stable release managers: when the planning for the next release starts,
backports should only be necessary for at most one past release.

Release managers should be separate and make separate decisions.
Release monkeys, in contrast, can well work in rotation across branches
so that the people doing the stable releases are not the one with the
least experience in rolling a release.

Our current system is based on the premise "how do we get to the stage
where Graham is comfortable doing all the release work and I don't need
to get involved?".  Graham is not comfortable doing technical decisions,
but he is comfortable designing policies, getting overall consent for
them, and following them.  And he is pretty good at it, too, and it is
not like there were no results, and not only because it motivates him to
work on the required infrastructure and makes him motivate others.

But the results on our stable releases don't work out yet, and I don't
see that they will work out in the near future unless we get lucky.  And
depending on luck seems like a bad idea.  Amendments to the policies
means that we change the ways and degrees to which we depend on luck.
It's like fiddling with motor parameters for a car that does not start.
Perhaps it is time to walk.  At least to the gas station.

-- 
David Kastrup