GNU bug report logs - #50009
28.0.50; add CRLF to outgoing ERC protocol logger lines

Previous Next

To add a comment to this bug, you must first unarchive it, by sending
a message to control AT debbugs.gnu.org, with unarchive 50009 in the body.
You can then email your comments to 50009 AT debbugs.gnu.org in the normal way.

Toggle the display of automated, internal messages from the tracker.

Message #5 received at submit <at> debbugs.gnu.org (full text, mbox):

From: "J.P." <jp <at> neverwas.me>
To: bug-gnu-emacs <at> gnu.org
Subject: 28.0.50; add CRLF to outgoing ERC protocol logger lines
Date: Wed, 11 Aug 2021 07:26:26 -0700

[Message part 1 (text/plain, inline)]

Tags: patch

Hi, this patch or similar would really make generating test data a lot
easier (please see the behavioral tests in these bugs [1] for examples).

If it were up to me, we'd also get rid of the interactive toggling, at
least while sessions are ongoing. The reason is that I find the most
interesting/important parts of a session to be the initial "connection
registration" phase and subsequent server burst (and possibly any
NickServ interactions and early JOIN activity that immediately follow).
But out of respect for tradition, I've left all of that alone. Thanks.


[1] https://debbugs.gnu.org/cgi/bugreport.cgi?bug=48598
    https://debbugs.gnu.org/cgi/bugreport.cgi?bug=49860


In GNU Emacs 28.0.50 (build 1, x86_64-pc-linux-gnu, GTK+ Version 3.24.30, cairo version 1.17.4)
 of 2021-08-09 built on localhost
Repository revision: aeec97fae0ccfcc4dc406a5e0e4c0a94b834cac4
Repository branch: master
Windowing system distributor 'The X.Org Foundation', version 11.0.12011000
System Description: Fedora 34 (Workstation Edition)

Configured features:
ACL CAIRO DBUS FREETYPE GIF GLIB GMP GNUTLS GPM GSETTINGS HARFBUZZ JPEG
JSON LCMS2 LIBOTF LIBSELINUX LIBSYSTEMD LIBXML2 M17N_FLT MODULES NOTIFY
INOTIFY PDUMPER PNG RSVG SECCOMP SOUND THREADS TIFF TOOLKIT_SCROLL_BARS
X11 XDBE XIM XPM GTK3 ZLIB

Important settings:
  value of $LANG: en_US.UTF-8
  value of $XMODIFIERS: @im=ibus
  locale-coding-system: utf-8-unix

Major mode: Lisp Interaction

Minor modes in effect:
  tooltip-mode: t
  global-eldoc-mode: t
  eldoc-mode: t
  electric-indent-mode: t
  mouse-wheel-mode: t
  tool-bar-mode: t
  menu-bar-mode: t
  file-name-shadow-mode: t
  global-font-lock-mode: t
  font-lock-mode: t
  blink-cursor-mode: t
  auto-composition-mode: t
  auto-encryption-mode: t
  auto-compression-mode: t
  line-number-mode: t
  indent-tabs-mode: t
  transient-mark-mode: t

Load-path shadows:
None found.

Features:
(shadow sort mail-extr emacsbug message rmc puny dired dired-loaddefs
rfc822 mml mml-sec epa derived epg epg-config gnus-util rmail
rmail-loaddefs auth-source cl-seq eieio eieio-core cl-macs
eieio-loaddefs password-cache json map text-property-search time-date
subr-x seq byte-opt gv bytecomp byte-compile cconv mm-decode mm-bodies
mm-encode mail-parse rfc2231 mailabbrev gmm-utils mailheader cl-loaddefs
cl-lib sendmail rfc2047 rfc2045 ietf-drums mm-util mail-prsvr mail-utils
iso-transl tooltip eldoc electric uniquify ediff-hook vc-hooks
lisp-float-type mwheel term/x-win x-win term/common-win x-dnd tool-bar
dnd fontset image regexp-opt fringe tabulated-list replace newcomment
text-mode elisp-mode lisp-mode prog-mode register page tab-bar menu-bar
rfn-eshadow isearch easymenu timer select scroll-bar mouse jit-lock
font-lock syntax font-core term/tty-colors frame minibuffer cl-generic
cham georgian utf-8-lang misc-lang vietnamese tibetan thai tai-viet lao
korean japanese eucjp-ms cp51932 hebrew greek romanian slovak czech
european ethiopic indian cyrillic chinese composite charscript charprop
case-table epa-hook jka-cmpr-hook help simple abbrev obarray
cl-preloaded nadvice button loaddefs faces cus-face macroexp files
window text-properties overlay sha1 md5 base64 format env code-pages
mule custom widget hashtable-print-readable backquote threads dbusbind
inotify lcms2 dynamic-setting system-font-setting font-render-setting
cairo move-toolbar gtk x-toolkit x multi-tty make-network-process emacs)

Memory information:
((conses 16 51538 6355)
 (symbols 48 6607 1)
 (strings 32 18255 1368)
 (string-bytes 1 616656)
 (vectors 16 14292)
 (vector-slots 8 185252 10153)
 (floats 8 21 47)
 (intervals 56 205 0)
 (buffers 992 10))

[0001-Add-CRLF-to-outgoing-ERC-protocol-logger-lines.patch (text/x-patch, attachment)]

Message #8 received at 50009 <at> debbugs.gnu.org (full text, mbox):

From: "J.P." <jp <at> neverwas.me>
To: 50009 <at> debbugs.gnu.org
Subject: Re: bug#50009: 28.0.50; add CRLF to outgoing ERC protocol logger lines
Date: Sun, 12 Sep 2021 05:04:28 -0700

[Message part 1 (text/plain, inline)]

v2. Tweaked some spacing and borrowed a unit test from bug#48598.

(Note: the first attachment just shows the changes from the last set and
is not itself a patch.)

[0000-v1-v2.diff (text/x-patch, attachment)]

[0001-Add-CRLF-to-outgoing-ERC-protocol-logger-lines.patch (text/x-patch, attachment)]

Message #11 received at 50009 <at> debbugs.gnu.org (full text, mbox):

From: "J.P." <jp <at> neverwas.me>
To: 50009 <at> debbugs.gnu.org
Subject: Re: bug#50009: 28.0.50; add CRLF to outgoing ERC protocol logger lines
Date: Sun, 12 Sep 2021 17:52:05 -0700

[Message part 1 (text/plain, inline)]

v3. Fix process-query-on-exit problem in unit test.

[0000-NOT-A-PATCH-v2-v3.diff (text/x-patch, attachment)]

[0001-Add-CRLF-to-outgoing-ERC-protocol-logger-lines.patch (text/x-patch, attachment)]

Message #14 received at 50009 <at> debbugs.gnu.org (full text, mbox):

From: "J.P." <jp <at> neverwas.me>
To: 50009 <at> debbugs.gnu.org
Subject: Re: bug#50009: 28.0.50; add CRLF to outgoing ERC protocol logger lines
Date: Sun, 12 Sep 2021 20:04:47 -0700

[Message part 1 (text/plain, inline)]

v4. Ugh, so the last one was still failing intermittently (on 27).
Should be good now.

[0000-NOT-A-PATCH-v3-v4.diff (text/x-patch, attachment)]

[0001-Add-CRLF-to-outgoing-ERC-protocol-logger-lines.patch (text/x-patch, attachment)]

Message #17 received at 50009 <at> debbugs.gnu.org (full text, mbox):

From: "J.P." <jp <at> neverwas.me>
To: 50009 <at> debbugs.gnu.org
Subject: Re: bug#50009: 28.0.50; add CRLF to outgoing ERC protocol logger lines
Date: Tue, 14 Sep 2021 02:22:18 -0700

[Message part 1 (text/plain, inline)]

v5. Having two styles of line terminator (both CRLF and LF) present in
the same buffer was dumb. So now it's just CRLF everywhere. I've also
explained a bit about the format in the doc string for the version
number variable. Thanks.

.

[0000-v4-v5.diff (text/x-patch, attachment)]

[0001-Add-CRLF-to-outgoing-ERC-protocol-logger-lines.patch (text/x-patch, attachment)]

Message #20 received at 50009 <at> debbugs.gnu.org (full text, mbox):

From: dick <dick.r.chiang <at> gmail.com>
To: "J.P." <jp <at> neverwas.me>
Cc: 50009 <at> debbugs.gnu.org
Subject: Re: bug#50009: 28.0.50; add CRLF to outgoing ERC protocol logger lines
Date: Tue, 14 Sep 2021 06:44:01 -0400

I think we can all agree this kind of "come to think of it" iteration is why
PR-based submission is superior to patches.

Message #23 received at 50009 <at> debbugs.gnu.org (full text, mbox):

From: Amin Bandali <bandali <at> gnu.org>
To: dick <dick.r.chiang <at> gmail.com>
Cc: 50009 <at> debbugs.gnu.org, "J.P." <jp <at> neverwas.me>
Subject: Re: bug#50009: 28.0.50; add CRLF to outgoing ERC protocol logger lines
Date: Tue, 14 Sep 2021 18:37:15 -0400

dick writes:

> I think we can all agree this kind of "come to think of it" iteration is why
> PR-based submission is superior to patches.

Do we?  What's superior about it?

Message #26 received at 50009 <at> debbugs.gnu.org (full text, mbox):

From: dick <dick.r.chiang <at> gmail.com>
To: Amin Bandali <bandali <at> gnu.org>
Cc: 50009 <at> debbugs.gnu.org, "J.P." <jp <at> neverwas.me>
Subject: Re: bug#50009: 28.0.50; add CRLF to outgoing ERC protocol logger lines
Date: Wed, 15 Sep 2021 12:35:00 -0400

Sigh, it pains me to have to add to the verbiage maelstrom that is debbugs
when the antiquity of GNU patch is self-evident.

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.

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.

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.

Message #29 received at 50009 <at> debbugs.gnu.org (full text, mbox):

From: Eli Zaretskii <eliz <at> gnu.org>
To: dick <dick.r.chiang <at> gmail.com>
Cc: 50009 <at> debbugs.gnu.org, bandali <at> gnu.org, jp <at> neverwas.me
Subject: Re: bug#50009: 28.0.50; add CRLF to outgoing ERC protocol logger lines
Date: Wed, 15 Sep 2021 20:15:51 +0300

> From: dick <dick.r.chiang <at> gmail.com>
> Date: Wed, 15 Sep 2021 12:35:00 -0400
> Cc: 50009 <at> debbugs.gnu.org, "J.P." <jp <at> neverwas.me>
> 
> Sigh, it pains me to have to add to the verbiage maelstrom that is debbugs
> when the antiquity of GNU patch is self-evident.

You are not helping, so please at least don't interfere.

There's no problem knowing which patch is the latest one, contrary to
your propaganda.

Message #32 received at 50009 <at> debbugs.gnu.org (full text, mbox):

From: dick <dick.r.chiang <at> gmail.com>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: 50009 <at> debbugs.gnu.org, bandali <at> gnu.org, jp <at> neverwas.me
Subject: Re: bug#50009: 28.0.50; add CRLF to outgoing ERC protocol logger lines
Date: Wed, 15 Sep 2021 13:49:46 -0400

EZ> You are not helping, so please at least don't interfere.

Your hamfisted use of the terms "helping" and "interfere" presuppose a notion
of progress, one which is premised on the status quo.

Message #35 received at 50009 <at> debbugs.gnu.org (full text, mbox):

From: Eli Zaretskii <eliz <at> gnu.org>
To: dick <dick.r.chiang <at> gmail.com>
Cc: 50009 <at> debbugs.gnu.org, bandali <at> gnu.org, jp <at> neverwas.me
Subject: Re: bug#50009: 28.0.50; add CRLF to outgoing ERC protocol logger lines
Date: Wed, 15 Sep 2021 21:13:17 +0300

> From: dick <dick.r.chiang <at> gmail.com>
> Cc: 50009 <at> debbugs.gnu.org,  bandali <at> gnu.org,  jp <at> neverwas.me
> Date: Wed, 15 Sep 2021 13:49:46 -0400
> 
> EZ> You are not helping, so please at least don't interfere.
> 
> Your hamfisted use of the terms "helping" and "interfere" presuppose a notion
> of progress, one which is premised on the status quo.

No, I mean helping and interfering with us, the maintainers, doing our
job.

Message #38 received at 50009 <at> debbugs.gnu.org (full text, mbox):

From: Amin Bandali <bandali <at> gnu.org>
To: dick <dick.r.chiang <at> gmail.com>
Cc: 50009 <at> debbugs.gnu.org, "J.P." <jp <at> neverwas.me>
Subject: Re: bug#50009: 28.0.50; add CRLF to outgoing ERC protocol logger lines
Date: Wed, 15 Sep 2021 20:03:24 -0400

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.

Message #41 received at 50009 <at> debbugs.gnu.org (full text, mbox):

From: dick <dick.r.chiang <at> gmail.com>
To: Amin Bandali <bandali <at> gnu.org>
Cc: 50009 <at> debbugs.gnu.org
Subject: Re: bug#50009: 28.0.50; add CRLF to outgoing ERC protocol logger lines
Date: Wed, 15 Sep 2021 20:20:22 -0400

> I've seen my fair share of similarly long yet considerably worse GitHub
> discussions

"Considerably worse" would be an understatement.  Verbosity is a function of
the age and number of participants, and Github skews unfavorably in both those
categories.

My point was the verbosity, a systemic cost to doing business, does not
under a PR-based workflow occlude the proposed changeset, whereas under
"wonderful" Debbugs the proliferation of proposed patches could.

Your raising the example of native-comp merely reinforces my point that
branch-based schemes are superior to ad hoc email-based ones.

It's clear we've already made our minds about it.  But you asked, so I
answered.  Pardon the "interference" to those trying to "do their job."

Message #44 received at 50009 <at> debbugs.gnu.org (full text, mbox):

From: Eli Zaretskii <eliz <at> gnu.org>
To: Amin Bandali <bandali <at> gnu.org>
Cc: 50009 <at> debbugs.gnu.org, dick.r.chiang <at> gmail.com, jp <at> neverwas.me
Subject: Re: bug#50009: 28.0.50; add CRLF to outgoing ERC protocol logger lines
Date: Thu, 16 Sep 2021 08:42:35 +0300

> From: Amin Bandali <bandali <at> gnu.org>
> Date: Wed, 15 Sep 2021 20:03:24 -0400
> Cc: 50009 <at> debbugs.gnu.org, "J.P." <jp <at> neverwas.me>
> 
> 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.

This discussion doesn't belong here.  Here we discus a specific issue
submitted to the Emacs issue tracker.  Broad discussions about our
development workflows should be held on emacs-devel.  Please move it
there (if you must have this discussion, which is about the umpteenth
time it is being brought up, including very recently).

Whatever you do, please STOP discussing it here.  Right now, the only
effect this has is to make following the discussions of bug#50009 much
harder by polluting it with unrelated messages, which are not even
tangents.

Message #47 received at 50009 <at> debbugs.gnu.org (full text, mbox):

From: Lars Ingebrigtsen <larsi <at> gnus.org>
To: "J.P." <jp <at> neverwas.me>
Cc: 50009 <at> debbugs.gnu.org
Subject: Re: bug#50009: 28.0.50; add CRLF to outgoing ERC protocol logger lines
Date: Thu, 16 Sep 2021 15:36:24 +0200

"J.P." <jp <at> neverwas.me> writes:

> v5. Having two styles of line terminator (both CRLF and LF) present in
> the same buffer was dumb. So now it's just CRLF everywhere. I've also
> explained a bit about the format in the doc string for the version
> number variable. Thanks.

Thanks; makes sense to me (and seems to work well when testing it), so
I've pushed it to Emacs 28.

-- 
(domestic pets only, the antidote for overdose, milk.)
   bloggy blog: http://lars.ingebrigtsen.no

Message #52 received at 50009 <at> debbugs.gnu.org (full text, mbox):

From: Richard Stallman <rms <at> gnu.org>
To: dick <dick.r.chiang <at> gmail.com>
Cc: 50009 <at> debbugs.gnu.org, bandali <at> gnu.org, jp <at> neverwas.me
Subject: Re: bug#50009: 28.0.50; add CRLF to outgoing ERC protocol logger lines
Date: Thu, 16 Sep 2021 20:13:56 -0400

[[[ To any NSA and FBI agents reading my email: please consider    ]]]
[[[ whether defending the US Constitution against all enemies,     ]]]
[[[ foreign or domestic, requires you to follow Snowden's example. ]]]

Can a PR-based workflow be made to operate via email, in a way that
doesn't require a net connection?  (Except, at some later time, for
committing a change.)  That is a requisite for us.

-- 
Dr Richard Stallman (https://stallman.org)
Chief GNUisance of the GNU Project (https://gnu.org)
Founder, Free Software Foundation (https://fsf.org)
Internet Hall-of-Famer (https://internethalloffame.org)

Message #55 received at 50009 <at> debbugs.gnu.org (full text, mbox):

From: dick <dick.r.chiang <at> gmail.com>
To: Richard Stallman <rms <at> gnu.org>
Cc: 50009 <at> debbugs.gnu.org, bandali <at> gnu.org, jp <at> neverwas.me
Subject: Re: bug#50009: 28.0.50; add CRLF to outgoing ERC protocol logger lines
Date: Thu, 16 Sep 2021 21:17:39 -0400

You may construe my reticence on the matter as dutiful compliance to the
maintainer's exhortations.

Message #58 received at 50009 <at> debbugs.gnu.org (full text, mbox):

From: Eli Zaretskii <eliz <at> gnu.org>
To: rms <at> gnu.org
Cc: 50009 <at> debbugs.gnu.org, bandali <at> gnu.org, dick.r.chiang <at> gmail.com,
 jp <at> neverwas.me
Subject: Re: bug#50009: 28.0.50; add CRLF to outgoing ERC protocol logger lines
Date: Fri, 17 Sep 2021 09:24:44 +0300

> From: Richard Stallman <rms <at> gnu.org>
> Date: Thu, 16 Sep 2021 20:13:56 -0400
> Cc: 50009 <at> debbugs.gnu.org, bandali <at> gnu.org, jp <at> neverwas.me
> 
> Can a PR-based workflow be made to operate via email, in a way that
> doesn't require a net connection?  (Except, at some later time, for
> committing a change.)  That is a requisite for us.

As I said, we should NOT discuss these matters in an unrelated bug
report.

Our prerequisite is not to have the PR workflow work via email, it is
that the maintainer's part of the workflow could be done via email.

Previous Next

GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.