Re: -dcrop not included in 2.20?

[David Kastrup]

Joram <address@hidden> writes:

> Hi David,
>
> I appreciate your work on lilypond and I have no reason to doubt your
> capability as the release manager for the upcoming 2.20 release.
>
> What is intransparent to me is, how the inclusion of patches into
> lilypond is decided. Is there a defined procedure?

For the development branch, there is the documented procedure in the
Contributor's Guide.

For the stable branch, this is the release manager's choice.  That's an
undemocratic job description in order to get consistent results.  The
release manager is to blame for every instability placed into the stable
branch after the branch-off point.

Obviously, if some functionality is important to you in _this_ stable
branch, the way to make sure to get it is to annoy the release manager
until he gives up, then volunteer as release manager yourself.

We are currently in the first stage of that process.

> I think it is obvious that someone who has written a patch (and not
> just put something on a wishlist) has some interest to see it
> included.

We are not talking about "included" here.  We are talking "part of the
very next stable release".  The bar for new functionality is rather
high.  Naturally, this is an unfair process as the release manager will
be more likely to vouch for his own patches than those of someone else.

> What I know from other collaborative software development is roughly this:
> - There is a proposed patch (pull request or similar)
> - There is some discussion
>   a) If all agree that is a good request it gets merged
>   b) If there are severe objections it gets rejected
>   c) If the basic idea is fine but there are things to improve, it can
>      be improved until it reaches a state that qualifies for merging.
> - Many ticket systems also have a "I am also affected" or "I also like
>   this" button - so asking again is nothing peculiar

Irrelevant.  That is the procedure for inclusion in master.  For stable
releases, you usually have responsible release managers.

> For the patch under discussion, you had no objections. As you wanted to
> be quoted, here is your statement:
>
>> Currently I am undecided.  The code is separated
>> well enough and clearly does not get exercised without specifying the
>> option.  So it's not going to harm existing functionality. 
>
> That's all positive. Sounds like (a) to me. Étienne asks why the logical
> next step (merging) is not done.

You don't listen.  Since that posting, _no_ merge work has been done on
the stable branch.  So no decision has been made, and yet I spent hours
and a lot of goodwill getting pestered by people who cannot understand
that something has not been included yet into something which has not
yet seen another revision.

> Could be (c), but unclear why 'this form' could require changes in the
> future. In the end, I understand your statement as "ready for
> merging".  But I am not 100% sure. Is it a matter of time or of
> objections?

If many more people object to what amounts to nothing at all, I am going
to refuse being responsible for the release any more.  In that case, it
will become a matter of time until someone else volunteers.

> Does that make it clearer why I am confused (and perhaps why Étienne
> was asking again)? It is really not meant as an offence. I am just
> trying to understand in which state this issue is.

The same as before, except that I am a whole lot more pissed.

-- 
David Kastrup