Re: development process

[David Kastrup]

Han-Wen Nienhuys <address@hidden> writes:

> On Wed, Feb 5, 2020 at 12:11 AM David Kastrup <address@hidden> wrote:
>
>> Where commits do not belong to the same logical issue but are still
>> interdependent, they cannot be logically disentangled even using a
>> Git-specific tool like Gerrit.
>>
>
> Oh, but you can. You can review the change as part of the dependent change,
> but then rebase or cherry-pick them if they can be submitted
> separately.

Then they would not be "interdependent".

>>    Because the review happens on the split-out patches, I now switch back
>> >    and forth between 34 different versions of LilyPond. Every time I
>> address a
>> >    review comment, I go through a lengthy recompile.
>>
>> Recompiles tend to be very fast unless you "make clean" in between or
>> check out, in the same work tree, vastly differing branches, like
>> switching between stable and unstable branches.
>>
>
> Guess what you have to do when working on GUILE 2? You edit central headers
> (recompile everything!) and after it works, compile against GUILE 1.8
> (recompile everything!) to make sure it doesnt break the build.

That would be an obvious choice for keeping two work directories.  Yes,
it requires organising your personal workspace.

>> But that's a side track.  As I already stated: my initial experience
>> with contributing involved patches to LilyPond was that they were
>> ignored because nobody considered themselves able or motivated to
>> review them.  Even simple changes took weeks to get accepted.  For
>> better or worse, there just aren't people responsible for large parts
>> of the code that would be able or willing to judge it on its merits
>> in the context of the LilyPond code base.
>>
>
> The process is not designed to address the lack of people. Rather, the
> idea is that contributing to LilyPond is an experience that is easier
> and more rewarding. From there, we might suck in more people because
> contributing is fun and rewarding.

Uh, I just described that when I started working on LilyPond, in a setup
with maintainers that were merely required to ok a change, contributing
to LilyPond was an experience that was anything other than easy and
rewarding.

> It is possible that we go back to a place where we can't accept
> changes to intricate code (markup macros, music functions?) unless
> they drastically simplify things, because no maintainers want to take
> on responsibility for something that is hard to understand. I think
> that is an acceptable tradeoff if we get more developers for the
> project overall.

I think your idea of the project wastes a humongous potential of
contributors that could benefit the LilyPond universe without even
getting involved with core programming.

Take a look at TeX: the core development is essentially dead.  A number
of offspring engines are done by small teams not numbering more than a
dozen active developers each.  There are likely hundreds of plain TeX
packages available, with plain TeX being a similarly thin layer around
the core engine than what LilyPond has.  And then there is LaTeX,
essentially in a version that stabilised in the 90s.  And ten thousands
of extensions for all purposes, layouts, and functionality built around
that.

You don't get to micromanage that amount of contributors.  The best you
can do is to offer a concentrator of completed ready-made effort like
TeXlive does.

If you choose to close off improving on stuff that depends on the
expertise of single persons investing themselves into a single task,
that has repercussions.

>> That was likely inappropriate by me, sorry for that.  I just pointed
>> out that what you considered detrimental would work in your interest
>> here.
>>
>
> I have said this before, and I'll repeat: I find your assumptions about my
> interests offending.

You already explained that you want your patches in faster.

> Please stop making them. I have dedicated 10 years of my life to
> LilyPond. I wrote most of its code, I spent countless hours as a
> maintainer, community leader, and user support person. What do you
> think my interest is?
>
>>    Uncontroversial changes can be submitted immediately after a maintainer
>> >    has LGTM’d it,
>>
>> Two problems with that: what is uncontroversial?  And who is a
>> maintainer?  You want less opportunity for people to raise objections,
>> but how can you decide about something being uncontroversial when people
>> don't get to review a patch and consider objections?
>>
>
> Maintainer: see below.
>
> Here is a definition: patches are uncontroversial when a maintainer
> says it's OK.
>
> Here is another definition: a patch is uncontroversial when it
> improves something and doesn't create long-term liability.
>
> Here is a practical example: when you look at, say
> https://codereview.appspot.com/577410045/, there is considerable
> discussion about a detail of using references vs. pointers, but the
> overall cleanup (adding comments, renaming variables) is a pretty
> straightforward improvement.

The controversy was not about that.

> I would call this patch uncontroversial, because it doesn't change a
> lot of code, and doesn't create future liabilities. In this case, the
> change could have been submitted, with further touch ups in follow-up
> changes.

We certainly don't want warring back-and-forth changes on code, so we
try operating on consensus on its goals.  I've contributed to other
projects like Git that instead depend on a "benevolent dictator" as
integrator, and it is utterly normal for them to accept contributions
only after all style questions have been satisfactorily addressed.  It
is also perfectly normal that you are going to be asked to explain
changes of previous conscious decisions made.

> Another example is https://codereview.appspot.com/561350044/ . This
> changed a return type in a couple of places. It went in, but I
> complained afterwards. It was reverted and redone in a different
> way. This patch doesn't take on future liabilities, so it doesn't need
> an extensive waiting period. We can fix it up afterwards if something
> is wrong..

In general, people are not overly happy with having their work reverted
once committed.  It happens.

> An example of a controversial patch: any kind of change to the input
> syntax. The input format is a user accessible part of the system, so
> if you expose a new feature, people will start using it and depending
> on it. If such a change stays available for long enough, we can't
> change our mind and back it out because we'd screw over our
> users. Syntax changes often also impact existing scores, and friendly
> neighbor projects, like Frescobaldi.  Changes like this need thorough
> scrutiny.

They also need convert-ly rules (unless they are extensions only).  And
warrant regtests and documentation.  The issue of "controversial"
usually implies that even the patch submitter does not really know in
advance whether they are really a good idea.

2.19 has seen a few such changes by me that now allow for writing
something like

\time 3,2 5/4

or

textcolor = \override Lyrics.LyricText.color = \etc

Either are essentially syntactic sugar for preexisting constructs, but
being able to write them in a "friendlier" and more convenient manner
actually means a lot to people.

Such changes were proposed and debated on the developer list and often
required a number of reiterations to hash out properly.

>> >    and automated tests pass. Merging such a change should be an
>> >    effortless single click, and should not involve mucking with the
>> >    git command line. Because submitting requires no effort, we won’t
>> >    have patches stuck because we’re too lazy to do the work of merging
>> >    them.  -
>>
>> Like which patch?
>>
>
> Weren't you complaining of patches that didn't get feedback?

When the process was as you want to have it again?  Yes, exactly.  I
just don't see how this should be counted as a point in favor of going
back to a system that didn't work for me then.

> I had the impression that part of the problem is that accepting
> patches used to require a non-zero amount of work, and this caused
> contributions to languish. Is that the case?

Correct.  Which is why my complaints got to the degree that Graham and
others decided to change the manner of vetting corrections, leading to
our current system regarding the human interaction.  You basically want
back to the old system that did not work for me.

> (maybe not for your patches, that were too complicated, but for other
> patches?)

Our current process is awkward technically, not because of the roles its
human players assume.

>> >    Right now, results from build/test are available during
>> >    review. This is a good thing, and we should keep it.
>> >    -
>>
>> It's a good thing, I agree on that.  "We should keep it" sounds like it
>> is a mechanical thing and a decision we can make.  It involves
>> significant work currently done by James.  And the automation he has
>> available to that purpose is in a decrepit state.  That's really an
>> embarrassment.  So we should not just "keep it" but hopefully also fix
>> significant parts of it to make them less manual.  This visual
>> comparison is something that is unique to LilyPond as a typesetter, and
>> there may be some effort involved getting a good workflow designed and
>> implemented working with a different tool.
>>
>
> Yes, I completely agree, and we should improve the infrastructure here.
>
>> > There is no “lack of feedback means it goes in”. By accepting a
>> > code contribution we implicitly take on the duty to maintain it and
>> > fix bugs in it.
>>
>> Who is we?
>>
>
> The project maintainers, see below.
>
>> >   If no maintainer can be convinced a piece of code is worth taking
>> >   it on, then that is a long-term maintenance risk, and it should
>> >   be rejected.  -
>>
>> Who are maintainers?
>>
>
> People who
>
> * agree to be committed with the project for the long term

People die or become otherwise unavailable.

> * have sufficient knowledge to make technical decisions to further the
> project goals

Vetting individual changes and architecting long-term project goals are
different endeavors.

> * have trust from the developer community.

Sure.

> In the distant past, that would be me & Jan. In the less distant past,
> that is Graham and you. There are other people well-versed in
> subcomponents that could be maintainers for particular aspects,
> eg. Dan for C++ specific questions, or Jonas for Python related
> issues.

Language skills and subcomponent knowledge are different.  LilyPond has
a lot of subcomponents, certainly more than languages, and there are
plenty of those as well.

Graham worked basically in an administrative role.  He was not in a
position to vet core patches.  A significant problem with the GLISS
project initiated during his tenure was that most of it had to be done
outside actual knowledge of the feasibility of implementing its
proposals, partly due to technical problems and constraints dictated by
LilyPond's implementation, partly due to logical fallacies.

In my tenure of lead programmer, I also was not competent in everything
that went in: backend and page breaking, even though I cleaned up some
of its infrastructure eventually in order to get rid of things nobody
understood, were not what I could really count on.  You yourself stated
when I asked you that I should rather contact Joe Neeman for information
about the page breaking design.

Basically I don't see that we realistically can offer a competent
maintainer for every area of LilyPond that could easily a-ok
contributions.

> I call these people maintainers as opposed to contributors, who would
> come and go more frequently.

And would want to give them different privileges.  In our current setup,
people with adminstrative privileges for bug tracker et al are typically
long-term participants that are not involved with code vetting, though
quite a bit with documentation.  They are often "meisters".  In
contrast, it is fairly easy to get commit privileges, and that's common
between comparatively basic contributors and "maintainers" such as me
(if you want to call it that) who also indulge in core programming work.

Obviously, I like this flat hierarchy where people are not "rewarded"
with privileges over others but one works according to one's capacity in
a mutually trusted environment where authority is never something you
can take for granted.

>> >    We have a patch meister whose job it is to hound the project
>> >    maintainer to look at patches that don’t find traction or
>> >    otherwise.
>>
>> That is not their current job description.
>>
>
> Yes, we would change the role of the patch meister. We could call it
> scrum master or something else.

It would appear that we do not have just technical changes to discuss.

-- 
David Kastrup