From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.io!.POSTED.blaine.gmane.org!not-for-mail From: "J.P." Newsgroups: gmane.emacs.bugs Subject: bug#48598: 28.0.50; buffer-naming collisions involving bouncers in ERC Date: Fri, 15 Apr 2022 18:12:55 -0700 Message-ID: <87h76tde5k.fsf__21047.5460322172$1650071668$gmane$org@neverwas.me> 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> <87h76ucrq4.fsf@gmx.de> Mime-Version: 1.0 Content-Type: text/plain Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="28704"; 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: Michael Albinus Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane-mx.org@gnu.org Sat Apr 16 03:14:18 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 1nfX0z-0007Br-9z for geb-bug-gnu-emacs@m.gmane-mx.org; Sat, 16 Apr 2022 03:14:17 +0200 Original-Received: from localhost ([::1]:35934 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1nfX0x-00048a-Sb for geb-bug-gnu-emacs@m.gmane-mx.org; Fri, 15 Apr 2022 21:14:15 -0400 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]:38118) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1nfX0m-00048J-0T for bug-gnu-emacs@gnu.org; Fri, 15 Apr 2022 21:14:04 -0400 Original-Received: from debbugs.gnu.org ([209.51.188.43]:38360) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.90_1) (envelope-from ) id 1nfX0j-000796-Va for bug-gnu-emacs@gnu.org; Fri, 15 Apr 2022 21:14:02 -0400 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1nfX0j-0007dQ-Lf for bug-gnu-emacs@gnu.org; Fri, 15 Apr 2022 21:14:01 -0400 X-Loop: help-debbugs@gnu.org Resent-From: "J.P." Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Sat, 16 Apr 2022 01:14: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.165007159429282 (code B ref 48598); Sat, 16 Apr 2022 01:14:01 +0000 Original-Received: (at 48598) by debbugs.gnu.org; 16 Apr 2022 01:13:14 +0000 Original-Received: from localhost ([127.0.0.1]:60490 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1nfWzy-0007cE-9q for submit@debbugs.gnu.org; Fri, 15 Apr 2022 21:13:14 -0400 Original-Received: from mail-108-mta210.mxroute.com ([136.175.108.210]:35979) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1nfWzt-0007by-BS for 48598@debbugs.gnu.org; Fri, 15 Apr 2022 21:13:12 -0400 Original-Received: from filter006.mxroute.com ([140.82.40.27] 140.82.40.27.vultrusercontent.com) (Authenticated sender: mN4UYu2MZsgR) by mail-108-mta210.mxroute.com (ZoneMTA) with ESMTPSA id 1802fee29ab000fe85.001 for <48598@debbugs.gnu.org> (version=TLSv1/SSLv3 cipher=ECDHE-RSA-AES128-GCM-SHA256); Sat, 16 Apr 2022 01:12:59 +0000 X-Zone-Loop: 119badc02bd2e6e6f424a11003c519a5ef140718ad94 X-Originating-IP: [140.82.40.27] DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=neverwas.me ; s=x; h=Content-Type:MIME-Version:Message-ID:In-Reply-To:Date:References: Subject:Cc:To:From:Sender:Reply-To:Content-Transfer-Encoding:Content-ID: Content-Description:Resent-Date:Resent-From:Resent-Sender:Resent-To:Resent-Cc :Resent-Message-ID:List-Id:List-Help:List-Unsubscribe:List-Subscribe: List-Post:List-Owner:List-Archive; bh=341AfL5FWsFgFiUvb8iIa/w4o2XbQJR8/OeB2nfSy+0=; b=H1xo9VKXAwSF79L4b4WKiWQimb YIiPLmVDeyumVrbQ6KHFVofPvYqJvyqwFlfnbNuuf6+NpucvEISkQdxOBulCPBeWVMzq4SH0ixp1U EVPJaN+sqZjc/KL51uXrBwaSkX09/XuXMUPloVk599+I2zFq4Irj34+rE4RVYG3UnLzTMjWSX4047 b6Ke+bf45zoWvPGqniHhDw/o0dg47aT0WoFZEZ7USzK5/iQzHt7T/V190Y+WJgwEoNh+o9I/tiW+l H0W4P3X6/wgG4F9//ZSDbaHRWJX7EH0pC4nnsBpGlaO2RLk0w8mQi69wCxqm7OSPyvVvOt8jn4RHX 7QfmWDpw==; In-Reply-To: <87h76ucrq4.fsf@gmx.de> (Michael Albinus's message of "Fri, 15 Apr 2022 17:05:07 +0200") X-AuthUser: masked@neverwas.me 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:229953 Archived-At: Michael Albinus 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.