lilypond-devel
[Top][All Lists]
Advanced

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

Re: make check is broken (again) - patch testing seeming to taking more


From: David Kastrup
Subject: Re: make check is broken (again) - patch testing seeming to taking more of my time than I like
Date: Mon, 28 Oct 2019 18:04:18 +0100
User-agent: Gnus/5.13 (Gnus v5.13) Emacs/27.0.50 (gnu/linux)

Dan Eble <address@hidden> writes:

> On Oct 28, 2019, at 08:12, David Kastrup <address@hidden> wrote:
>> 
>>> I request some help to understand how I can improve my pre-commit
>>> testing procedures, and where my responsibilities begin and end.
>> 
>> Responsibilities don't end.
>
> Fine.  When a patch is submitted for review, there ends the
> opportunity to fulfill one's responsibility to test before submitting
> it.  My question was how much is enough.
>
>> We don't have as comprehensive tests as that and don't really demand
>> it.  One should just be conservative.  The cost of a mistake in that
>> regard may well be a revert or a timely followup patch.
>
> This is an answer to my question, though my recent perception (which
> is possibly incorrect) was that receiving some public heat was
> included in the cost.

Before our automated testing procedures, it happened more often.  People
get annoyed when their workflow is disrupted.  Changes affecting the
build system are a bit more prone to fall through the cracks of testing,
particularly where older versions of tools (like in GUB) are possibly
affected.

> Anyway, I'm sorry that my recent contributions haven't worked for
> everyone; it's not for lack of trying.

Your track record is pretty good.  The last revert was quite likely
GUB-tool-version related: those are more likely than a lot of other
things to fall through the cracks of testing and just become apparent
before next release.  It's good that more people check with GUB nowadays
in time, but it's not part of our regular testing setup.

Maybe that last revert (possibly only appearing with GUB) was not
necessary for getting James back on track: I don't know.  But given the
importance of his work, I'd rather do a revert too much: they are
comparatively cheap.  This change needed to get dialed back in syntax at
some point of time before next release, anyway, so the difference of
reverting and not reverting is not all that much: one has to put some
more work either way.

-- 
David Kastrup



reply via email to

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