Re: Grow heap aggressively during music interpretation (issue 561390043 by address@hidden)

[David Kastrup]

Han-Wen Nienhuys <address@hidden> writes:

> On Mon, Feb 3, 2020 at 9:35 AM Han-Wen Nienhuys <address@hidden> wrote:
>> > > For me, juggling 15 different outstanding code reviews at the same
>> > > time is the bane of the current development process.
>> >
>> > what do you suggest?
>>
>> I think we should move to a git-based code review tool; Github, Gitlab
>> or Gerrit.  Gerrit is probably the closest to the current workflow.
>
> I think it would also be good if we can find a mode in which we get
> rid of the "countdown". Instead of waiting for complaints, a change is
> pushed once it passes tests and someone LGTM'd it.

If I may remind you, that was the effective state when I started on
LilyPond.  I submitted several patches that improved upon internals, so
nobody currently active felt up to giving a comment or LGTM.  Eventually
I raised such a shitstorm over this complete blockage of new work that
in the aftermath of dealing with it (that eventually led to the adoption
of rules and procedures more amenable to new developers) Valentin left.
I am not proud of that outcome.

I have a Guile patch submitted in this state of waiting for "someone
LGTM it" for 6 years already
<https://debbugs.gnu.org/cgi/bugreport.cgi?bug=17474> because it
involves internals of Guile, so people will rely on Andy Wingo for the
LGTM and Andy Wingo cannot be arsed to even comment.

That is a very dissatisfactory state particularly for newcomers since it
draws a sharp and terminal dividing line between newcomers to the
project and existing members who can just go ahead pushing their own
patches or rely on stock LGTMs by others.

We did not adopt the current system in a vacuum, we adopted it to
address a situation that was very frustrating for new developers.

> If we discover a problem with the change afterwards, we could simply
> revert it and discuss further.

Let me make this clear: you are currently in the process of submitting
patches that change code conventions from current C++ practice used by
current contributors to standards you decided on decades ago for your
own work on LilyPond.  If you follow the current discussion, how many
LGTMs on those changes do you count?  Our rules give you a chance at
outsitting objections until your patch makes it in by default.  If you
instead had to wait for an LGTM, you'd be held up for an indefinite
time.  People could just ignore you and your work would never get
anywhere, unless you use your commit privileges to ignore the process.

That's the way things were handled when I started working on LilyPond,
and it is not, in my book, a state worth returning to.

In short: your proposed solution would not address your problem if you
took reviews seriously.  Instead you would have to rely on ignoring what
people say and go ahead anyway.

That is an approach that does not scale to projects of arbitrary size.

-- 
David Kastrup