bug#50009: 28.0.50; add CRLF to outgoing ERC protocol logger lines

[Amin Bandali]

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.