From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.io!.POSTED.blaine.gmane.org!not-for-mail From: Michael Albinus Newsgroups: gmane.emacs.bugs Subject: bug#48598: 28.0.50; buffer-naming collisions involving bouncers in ERC Date: Fri, 15 Apr 2022 17:05:07 +0200 Message-ID: <87h76ucrq4.fsf__49866.6018642084$1650035177$gmane$org@gmx.de> References: <875yzakzvi.fsf@neverwas.me> <87leweez89.fsf@neverwas.me> <87fsmlp0gy.fsf@gnus.org> <878rsc2gp5.fsf_-_@gmx.de> <878rsbdipd.fsf@gnus.org> <87sfqjvjcx.fsf@neverwas.me> <87sfqi2119.fsf@gmx.de> <87v8vah54l.fsf@neverwas.me> Mime-Version: 1.0 Content-Type: text/plain Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="3403"; mail-complaints-to="usenet@ciao.gmane.io" User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/29.0.50 (gnu/linux) Cc: 48598@debbugs.gnu.org, Lars Ingebrigtsen , emacs-erc@gnu.org To: "J.P." Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane-mx.org@gnu.org Fri Apr 15 17:06:10 2022 Return-path: Envelope-to: geb-bug-gnu-emacs@m.gmane-mx.org Original-Received: from lists.gnu.org ([209.51.188.17]) by ciao.gmane.io with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from ) id 1nfNWT-0000f1-TR for geb-bug-gnu-emacs@m.gmane-mx.org; Fri, 15 Apr 2022 17:06:10 +0200 Original-Received: from localhost ([::1]:38200 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1nfNWS-0005Km-Eg for geb-bug-gnu-emacs@m.gmane-mx.org; Fri, 15 Apr 2022 11:06:08 -0400 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]:48778) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1nfNWM-0005Ke-Ic for bug-gnu-emacs@gnu.org; Fri, 15 Apr 2022 11:06:02 -0400 Original-Received: from debbugs.gnu.org ([209.51.188.43]:37949) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.90_1) (envelope-from ) id 1nfNWM-0000T1-AU for bug-gnu-emacs@gnu.org; Fri, 15 Apr 2022 11:06:02 -0400 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1nfNWL-0000Vx-UW for bug-gnu-emacs@gnu.org; Fri, 15 Apr 2022 11:06:01 -0400 X-Loop: help-debbugs@gnu.org Resent-From: Michael Albinus Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Fri, 15 Apr 2022 15:06:01 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 48598 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: patch Original-Received: via spool by 48598-submit@debbugs.gnu.org id=B48598.16500351221923 (code B ref 48598); Fri, 15 Apr 2022 15:06:01 +0000 Original-Received: (at 48598) by debbugs.gnu.org; 15 Apr 2022 15:05:22 +0000 Original-Received: from localhost ([127.0.0.1]:60079 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1nfNVi-0000Ux-6T for submit@debbugs.gnu.org; Fri, 15 Apr 2022 11:05:22 -0400 Original-Received: from mout.gmx.net ([212.227.17.20]:38321) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1nfNVe-0000Ue-A6 for 48598@debbugs.gnu.org; Fri, 15 Apr 2022 11:05:20 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=gmx.net; s=badeba3b8450; t=1650035109; bh=pfeBAm27nCj6fimtM0b1o40qkQTiqAh8Lh/3sJXeFQI=; h=X-UI-Sender-Class:From:To:Cc:Subject:References:Date:In-Reply-To; b=PDpyaosVbib7F5h+PETovn+QQ0SaAfqSM/cd4eC9gDGHM38uBdJeIhgO1OHL+D/sL 9EXkG+E74lpXWny2b6XUTxbObgaxZ6wlhKGLc0pqwuQ2TcESUKoza3PKFkLChwAtAm nCiqLkMuJa9ii4sDMIa2sSo6jUBsXLw1VmoSGw+4= X-UI-Sender-Class: 01bb95c1-4bf8-414a-932a-4f6e2808ef9c Original-Received: from gandalf.gmx.de ([213.220.156.81]) by mail.gmx.net (mrgmx105 [212.227.17.168]) with ESMTPSA (Nemesis) id 1MMXQF-1nPEEV3k2h-00JbLW; Fri, 15 Apr 2022 17:05:09 +0200 In-Reply-To: <87v8vah54l.fsf@neverwas.me> (J. P.'s message of "Fri, 15 Apr 2022 06:02:02 -0700") X-Provags-ID: V03:K1:51+M7G+QeysrfmhtuxIK7CC2Fxnpu2XXB4V7Y5tXTNt17e4Ud2m tP9G/RhjHjPpMEW6nvlKQzC1c7Etj1QJ2Ob+YORw3NSGK8xELOMpt18FdCPUuGBamx23HPg voWx62ev8ybmiwzWFIuaT+2NAhl6qS6c6YvttLXqTnCpbRfbJNFy0gL6B2N0E5Fv8tWSvYB riwf8qIGBGz0vEAoijrZA== X-UI-Out-Filterresults: notjunk:1;V03:K0:fHf677eXAW4=:LhGzfo7L60FlcaPnHPtTQs 5LBlyH9Uuih5dOgrBichDVxopv83ZJRJVkG6ypymu7CanGtx59Dni1BjIxCJEPL5y+ZA4Lhp4 kYwmrIRefHI7dn4ZN2CNGo8sh0VMyLGbZfLt2z+nU9pJ0d7FJRFTuGuum6ycycnSA2TcbEtWq BAWeVrykZ6rcvJzAWbYbR0IHTnp3Agt9mzexFng3V1wSqr9uxJ6ZZSniWlsewOaU1YDLOvgZz +AqgvKSQeXMy+aV5DdYQGZBIVAOuI5iidpD+un/Y75a/0X/jvdrWfWh0FBNlbt/Q7zPrgFS2P ZaPiwFN91Bohx8Pv391Jz3dyAABfmZVBB+cz1xZ1W/HFYMYjUFPFYit9+GsvfnIxNO3aJlrXn XonvkLPrCEe3aVjyBTQJfouYoYj/46ToNNXp1GD4flGGWk3sxBBYJu0ZyB1znNpMzhEAaz0rq QKzAIwdpOkJ8SjMsO0n2CzHNCGM31KebQU+Lnr7hWgJuYnk/3eG7iiMkR85Ml3EBEBrId0DgX 0KO9MwHF2BB/zOBtr2XJKUSr46/PTILZvoTPk9xGhhpi9auA/EJdPxOUMarffEHgc/mKUlAQH uVoQMStFooOJ/gsxKSvjWzziQZ+U9/PLt8iQuyZm/9SGMeg48DY+NuplNRQHY7QGbaBSZZhOl FORTAXYmBl+TSYL/vv3Z1Yz9N/W8d6A1tWJj5DEsyYifeuwzpMAZiqjqCEVhXlWfYf7nmPumS vqqKy3jt9dHXsrJk0wx7AlcgSJDBHA3OB+LHDE4qy9ZIu0g3/P/6xTsoICT6IlkTQNmzezON X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list X-BeenThere: bug-gnu-emacs@gnu.org List-Id: "Bug reports for GNU Emacs, the Swiss army knife of text editors" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane-mx.org@gnu.org Original-Sender: "bug-gnu-emacs" Xref: news.gmane.io gmane.emacs.bugs:229936 Archived-At: "J.P." writes: > Hi Michael, Hi, > 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]. These jobs are included via test/infra/test-jobs.yml. 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?) As you see in test/infra/Makefile, we apply already special cases for subdirectories, namely src, eieio, faceup, so-long, and misc. If we need to handle other special cases, it shall be in that Makefile. As I see in your patches, you're going this way. 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. > 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). 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. > 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. Again, there are several sub- and subsubdirectories in test/*. It cannot be decided by the generator how they depend on each other. One case waiting for optimization is test/lisp/cedet with several subsubdirectories. 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))'" If you haven't unstable tests, "SELECTOR=t" would work as well. 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. > 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. > > Thanks, > J.P. > > P.S. I'll try and refrain from bothering you again in the (immediate) > future. Thanks for this. These days, I'm affected with some health problems, so I cannot guarantee any reply in time. That's why I also gave your patches a cursory reading only, w/o being able to comment on them in detail just now. But I'll try to reply whenever you have further proposals; I'm interested in your proposed changes. > [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 (?). No, you must regenerate and push test/infra/test-jobs.yml as said above. > [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 > thought.) 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. > [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). Best regards, Michael.