Re: clear policy discussions

[Janek Warchoł]

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.

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

best,
Janek