unofficial mirror of bug-gnu-emacs@gnu.org 
 help / color / mirror / code / Atom feed
From: Amin Bandali <bandali@gnu.org>
To: dick <dick.r.chiang@gmail.com>
Cc: 50009@debbugs.gnu.org, "J.P." <jp@neverwas.me>
Subject: bug#50009: 28.0.50; add CRLF to outgoing ERC protocol logger lines
Date: Wed, 15 Sep 2021 20:03:24 -0400	[thread overview]
Message-ID: <87bl4ts7xv.fsf@gnu.org> (raw)
In-Reply-To: <87lf3xpzkb.fsf@dick>

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.





  parent reply	other threads:[~2021-09-16  0:03 UTC|newest]

Thread overview: 18+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2021-08-11 14:26 bug#50009: 28.0.50; add CRLF to outgoing ERC protocol logger lines J.P.
2021-09-12 12:04 ` J.P.
2021-09-13  0:52 ` J.P.
2021-09-13  3:04 ` J.P.
2021-09-14  9:22 ` J.P.
2021-09-14 10:44   ` dick
2021-09-14 22:37     ` Amin Bandali
2021-09-15 16:35       ` dick
2021-09-15 17:15         ` Eli Zaretskii
2021-09-15 17:49           ` dick
2021-09-15 18:13             ` Eli Zaretskii
2021-09-16  0:03         ` Amin Bandali [this message]
2021-09-16  0:20           ` dick
2021-09-16  5:42           ` Eli Zaretskii
2021-09-17  0:13         ` Richard Stallman
2021-09-17  1:17           ` dick
2021-09-17  6:24           ` Eli Zaretskii
2021-09-16 13:36   ` Lars Ingebrigtsen

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

  List information: https://www.gnu.org/software/emacs/

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=87bl4ts7xv.fsf@gnu.org \
    --to=bandali@gnu.org \
    --cc=50009@debbugs.gnu.org \
    --cc=dick.r.chiang@gmail.com \
    --cc=jp@neverwas.me \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
Code repositories for project(s) associated with this public inbox

	https://git.savannah.gnu.org/cgit/emacs.git

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).