[Top][All Lists]

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

Re: bug#48598: 28.0.50; buffer-naming collisions involving bouncers in E

From: J.P.
Subject: Re: bug#48598: 28.0.50; buffer-naming collisions involving bouncers in ERC
Date: Fri, 15 Apr 2022 06:02:02 -0700
User-agent: Gnus/5.13 (Gnus v5.13) Emacs/29.0.50 (gnu/linux)

Hi Michael,

Michael Albinus <michael.albinus@gmx.de> writes:

> The test targets for EMBA are generated. If there is a subdirectory
> test/lisp/erc/erc-d, a respective target will appear.
> The test-all-inotify job covers all tests, also the tests in 
> subsubdirectories.
> Best regards, Michael.

Thanks for patiently explaining yet again. I really should've been more
mindful of your time and studied up a bit before reaching out. But if
you'll allow me more excuses, part of what threw me about the
subdir-discovery situation was that the "normal" stage of the initial
(new branch) pipeline of fix/bug-48598 didn't include a job named
test-lisp-erc-erc-d-inotify [1].

And not that this matters in the slightest, but in an ideal world, *all*
of ERC's stable tests would *always* run (including the expensive ones),
both for jobs in diff-based, push pipelines (test-lisp-erc*-inotify) and
those in the thrice-daily, scheduled ones (test-all-inotify). Also ideal
would be having those tests that live in subdirs of test/lisp/erc (such
as test/lisp/erc/erc-d) run as part of the "main" job
(test-lisp-erc-inotify) rather than only when some change touches their
little area.

FWIW, I've attached some shoddy infra-related patches, mainly as a means
of better illustrating the aforementioned pie-in-the-sky behavior [2].
Regardless, I realize that giving ERC special treatment is likely not in
the cards. As such, I'm planning on rigging up our own CI setup for
testing proposed changes that hit the bug tracker (especially against
older Emacs versions) [3]. When the time comes, any guidance you might
spare will be greatly appreciated.


P.S. I'll try and refrain from bothering you again in the (immediate)

[1] https://emba.gnu.org/emacs/emacs/-/pipelines/16954

    I suppose that's because it was based on a preexisting
    test/infra/test-jobs.yml (?).

[2] That said, a flimsy rationale for the first one might be that it
    makes it slightly easier on external tooling trying to leverage
    existing in-tree recipes (but that's probably a stretch). Right now,
    I'm doing stuff like

    make -C test SELECTOR="(...)" check-lisp-foo

    everywhere. Not a major hassle, but it'd be nice to skip the
    SELECTOR part, especially when invoking Make by hand. (Just a

[3] If anyone out there cares, it'll also deploy ERC packages built from
    open bug sets to our own little ELPA to make it easier on everyday
    folks wanting to give feedback on proposed changes. Actually, we've
    already been doing all of this for over a year, only this time
    around, the idea is to make it less amateurish and have it run on
    Savannah or somewhere other than big cloud infra.

Attachment: 0001-POC-CHECK-Add-check-expensive-prefixes-for-test-subd.patch
Description: Text Data

Attachment: 0002-POC-CHECK-Allow-check-expensive-target-for-generated.patch
Description: Text Data

Attachment: 0001-POC-GROUP-Allow-shared-triggering-of-subdir-tests.patch
Description: Text Data

Attachment: test-jobs-check.diff
Description: Text Data

Attachment: test-jobs-check-want.yml
Description: Binary data

Attachment: test-jobs-group.diff
Description: Text Data

Attachment: test-jobs-group-want.yml
Description: Binary data

Attachment: test-jobs-orig.yml
Description: Binary data

reply via email to

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