lilypond-devel
[Top][All Lists]
Advanced

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

Re: Grow heap aggressively during music interpretation (issue 561390043


From: David Kastrup
Subject: Re: Grow heap aggressively during music interpretation (issue 561390043 by address@hidden)
Date: Mon, 03 Feb 2020 16:05:59 +0100
User-agent: Gnus/5.13 (Gnus v5.13) Emacs/28.0.50 (gnu/linux)

Dan Eble <address@hidden> writes:

> On Feb 3, 2020, at 04:30, Han-Wen Nienhuys <address@hidden> wrote:
>> 
>> Instead of waiting for complaints, a change is
>> pushed once it passes tests and someone LGTM'd it.
>
> I've worked in places where commits were handled with self-discipline
> and mutual accountability, and I've worked in places where a UI
> enforced upper-management's policy that every change had to be
> approved by two other developers before it could be merged.  I prefer
> self-discipline and mutual accountability to having to nag people with
> a superficial understanding of a change to put themselves on record as
> approving it.
>
> Therefore, regarding the countdown, I think it's a bad idea to require
> approval before pushing, unless we grant that the patch meister can
> approve pushing with the reason "countdown complete."
>
> Regarding accelerating the process, I wouldn't have a problem with a
> developer pushing a change after tests have passed, after receiving
> the clear approval of a developer competent in the subject, and when
> others aren't likely to disagree.  It would take a little more trust
> and clarity of feedback than always waiting for the countdown.  I
> don't expect that it would be the norm.

It does happen, and different developers are differently comfortable
taking the responsibility for bypassing the opportunity of feedback
depending on the situation.  The staging procedure reduces the potential
size of consequences of such a step, even in case of completely
bypassing any kind of review for trivial changes (trivial typically also
implying that no computer-interpreted syntax is changed).  It mostly
makes sense where it is unexpected others will comment, or when in the
course of larger interdependent changes that cannot be defused by
rebases, the queue is expected to continue stalling for prolonged
amounts of time.

-- 
David Kastrup



reply via email to

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