From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.io!.POSTED.blaine.gmane.org!not-for-mail From: Amin Bandali Newsgroups: gmane.emacs.bugs Subject: bug#50009: 28.0.50; add CRLF to outgoing ERC protocol logger lines Date: Wed, 15 Sep 2021 20:03:24 -0400 Message-ID: <87bl4ts7xv.fsf@gnu.org> References: <87v94chxbh.fsf@neverwas.me> <87czpb4ilx.fsf@neverwas.me> <87v9335te6.fsf@dick> <87lf3y7pic.fsf@gnu.org> <87lf3xpzkb.fsf@dick> Mime-Version: 1.0 Content-Type: text/plain Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="3964"; mail-complaints-to="usenet@ciao.gmane.io" User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/28.0.50 (gnu/linux) Cc: 50009@debbugs.gnu.org, "J.P." To: dick Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane-mx.org@gnu.org Thu Sep 16 02:04:12 2021 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 1mQesu-0000s5-EL for geb-bug-gnu-emacs@m.gmane-mx.org; Thu, 16 Sep 2021 02:04:12 +0200 Original-Received: from localhost ([::1]:50266 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1mQess-00071Z-Oi for geb-bug-gnu-emacs@m.gmane-mx.org; Wed, 15 Sep 2021 20:04:10 -0400 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]:35244) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1mQesl-000710-5Q for bug-gnu-emacs@gnu.org; Wed, 15 Sep 2021 20:04:03 -0400 Original-Received: from debbugs.gnu.org ([209.51.188.43]:41909) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.90_1) (envelope-from ) id 1mQesk-0004zf-U3 for bug-gnu-emacs@gnu.org; Wed, 15 Sep 2021 20:04:02 -0400 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1mQesk-0006Vs-Ga for bug-gnu-emacs@gnu.org; Wed, 15 Sep 2021 20:04:02 -0400 X-Loop: help-debbugs@gnu.org Resent-From: Amin Bandali Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Thu, 16 Sep 2021 00:04:02 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 50009 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: patch Original-Received: via spool by 50009-submit@debbugs.gnu.org id=B50009.163175061625004 (code B ref 50009); Thu, 16 Sep 2021 00:04:02 +0000 Original-Received: (at 50009) by debbugs.gnu.org; 16 Sep 2021 00:03:36 +0000 Original-Received: from localhost ([127.0.0.1]:53455 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1mQesK-0006VE-2o for submit@debbugs.gnu.org; Wed, 15 Sep 2021 20:03:36 -0400 Original-Received: from eggs.gnu.org ([209.51.188.92]:46268) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1mQesG-0006V0-PR for 50009@debbugs.gnu.org; Wed, 15 Sep 2021 20:03:35 -0400 Original-Received: from fencepost.gnu.org ([2001:470:142:3::e]:60216) by eggs.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1mQesA-0004WQ-LZ; Wed, 15 Sep 2021 20:03:26 -0400 Original-Received: from [2607:fea8:3fdf:f2d9:a862:b3ff:bd8c:7958] (port=42928 helo=langa) by fencepost.gnu.org with esmtpsa (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1mQesA-0002qd-G1; Wed, 15 Sep 2021 20:03:26 -0400 In-Reply-To: <87lf3xpzkb.fsf@dick> 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:214441 Archived-At: dick writes: > Sigh, it pains me to have to add to the verbiage maelstrom that is debbugs > when the antiquity of GNU patch is self-evident. To be clear, GNU is by far not the only project that uses patch-driven workflows. > A maintainer's sanity is inversely related to how much reading he has to do. > In a PR-based workflow, the changeset is unambiguous. On a platform like > Github, the changeset is manifest (in pretty colors) from the "Files Changed" > tab in a PR submission. Eleventh-hour revisions get incorporated without fuss > via the mild genius of git. I don't see how a GitHub-like interface which separates code from surrounding context/discussion is any more helpful. PR comments are also meant to be read and responded to -- much like email threads -- only they're more poorly implemented and often require a full blown web browser to interact with. I get the 'pretty colors' and syntax highlighting in my MUA (email client), which happens to be Emacs-based, just fine. For Emacs, there's even a wonderful 'debbugs' package on GNU ELPA that I highly encourage folks to try, if they use the debbugs bug tracker regularly. > Here, OP has submitted several changesets, of which only the chronologically > latest he wishes the maintainer to consider. To ascertain this fact, the > maintainer must read, and recall his happiness is inversely proportional to > how much reading he has to do. I mean, using a decent MUA one could easily skip or move back and forth between various replies in a thread, and fairly quickly tell which attached patch needs review/merging, like Eli alluded to. > In a cluster**** like bug#45474 where literally every one and their third > cousin is espousing a changeset, the maintainer not only has to read, he has > to decide, and that is a whole other circle of hell. The programmer's > tendency to pontificate and obfuscate (of which the present missive is a fine > example) does not help matters. I'm not sure what to say to this, other than 1. those sound to me like rather unkind characterizations of the people involved in that discussion and their work, and 2. I've seen my fair share of similarly long yet considerably worse GitHub discussions/comments. As far as I could tell from a quick glance, people in bug#45474 seem to be discussing/collaborating in good faith, and amicably. Yet I wouldn't attribute that to the underlying piece of software (Debbugs) or workflow (patch-based) being used. To wrap up this wall of text and move on, I get that different people have different preferences of workflow, but I don't see how the things you said describe any inherent advantage/"superior"ity of the PR-based workflow. If your point is about pushing code to some branch for review and subsequent updates being more convenient, people already do that for larger changes to Emacs (e.g. native-comp) by developing their work in an auxiliary 'feature/...' branch in emacs.git, which is then reviewed and hopefully merged into the main development branch at some point.