[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: clear policy discussions

From: David Kastrup
Subject: Re: clear policy discussions
Date: Fri, 13 Jul 2012 17:27:57 +0200
User-agent: Gnus/5.13 (Gnus v5.13) Emacs/24.1.50 (gnu/linux)

Janek Warchoł <address@hidden> writes:

> i said that i'll post an answer to this thread, so here it is :)
> David and Graham are clearly speaking from two different points of
> view.  Or, to be (hopefully) more accurate, they are on two orthogonal
> planes.
> David is an experienced developer.  He can judge LilyPond code better
> than many of us;

Nope, just the input layer.

> no set of rules is necessary for him to determine if LilyPond is, for
> example, ready for a stable release.  Thus, he is worried when he sees
> us /too strictly/ following suboptimal rules - he knows when we should
> make an exception.  This point of view is important, because it's the
> policies that should serve LilyPond - not the other way round.
> 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.

> 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.
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.

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.

And this negative feedback loop has to end.

David Kastrup

reply via email to

[Prev in Thread] Current Thread [Next in Thread]