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

Michael Albinus <[email protected]> writes:

> These days, I'm affected with some health problems, so I cannot
> guarantee any reply in time.

So sorry to hear about your situation. If there's anything I can help
with in terms of knowledge preservation and continuity of operations,
please let me know. Although my skills are rather limited (relatively
speaking), I am quite adept at being loud and pushy, if that's of any
use.

Best wishes,
J.P.

P.S. I've commented on your other remarks, below, mainly for posterity;
please don't trouble yourself, unless you are bored.


> And, as the header line of this file says, it is generated by "make
> generate-test-jobs". I'd like to keep this workflow. If you want a new
> subdirectory erc/erc-d being handled, you must regenerate this file,
> and commit it (maybe this needs to be explained more descriptively?)

Nah, that header explains things plainly enough. That I saw it and still
managed to miss its broader implications just goes to show that some
people can't be helped.

> If it is just about your fix/bug-48598 branch, you can change whatever
> you want. Of course, you can test the new emba workflow. But if you,
> OTOH, just want to run a test for a given bug, you can provide a short
> test/infra/gitlab-ci.yml with one or two jobs exactly for this purpose.

That's lovely! I'll be (over)doing this from now on.

> It was a design goal to run only non-expensive tests immediately after
> applying changes to the sources, in order to see problems fast. That's
> why the expensive tests are located in the fat test-all-inotify job
> only, running three timws a day. It is the responsibility of the
> developer to decide, whether a test is essential, it shouldn't be tagged
> as :expensive-test then.

I have further thoughts and questions about this (some likely unpopular)
but will save them for another discussion.

> If you are able to define such dependencies in the Makefile, and specify
> for erc
>
>     make_params: "-k -C test check-lisp-erc check-lisp-erc-erc-d"
>
> as special case, we're done. And if you really insist in running also
> expensive tests, apply
>
>     make_params: "-k -C test check-lisp-erc check-lisp-erc-erc-d SELECTOR='(not (tag :unstable))'"
>

That's exactly what we (I) do in ERC's external CI/CD. And that's where
I think we ought to leave things, for now (external/independent, that
is). As far as EMBA is concerned, I'd rather just go with the flow and
not rock the boat.

> There is no need to declare additional Makefile targets like
> check-expensive-lisp-erc, we have selectors. See for example
> test-native-comp-speed0 in test/infra/gitlab-ci.yml.

Right. I guess I wrongly convinced myself that SELECTOR was something
meant to be used internally or for edge cases.

> At least for emba recipes, there's no hassle. And also for manual calls
> I prefer the SELECTOR approach. In my tramp-tests.el, I have declared
> more tags but the "official" ones described in README, so I always need
> to discriminmate by SELECTOR. Not a big deal with shell's history.

I am often in an ephemeral container. But copy-pasting is simple enough,
so, no, no hassle. I shouldn't have brought it up. (Forgive me.)

>> [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.
>
> This I don't understand. Perhaps, we can discuss this later (I have a
> vague idea on running CI/CD tests for ELPA packages on emba).

I likewise shouldn't have brought this up either. We (I) have a separate
CI/CD workflow spanning a few interdependent GitLab.com projects.
There's also a package.el-compatible endpoint for (my) ERC patches,
currently located here:

  https://jpneverwas.gitlab.io/erc-tools/archive/

Though functional, it's of poor quality (hence "amateurish") and needs
to be redone and relocated.