unofficial mirror of emacs-devel@gnu.org 
 help / color / mirror / code / Atom feed
From: Karl Fogel <kfogel@red-bean.com>
To: Michael Albinus <michael.albinus@gmx.de>
Cc: Kyle Meyer <kyle@kyleam.com>, emacs-devel@gnu.org
Subject: Re: Improving documentation of Org Mode integration into Emacs.
Date: Mon, 10 Jan 2022 10:20:27 -0600	[thread overview]
Message-ID: <87ilurftpw.fsf@red-bean.com> (raw)
In-Reply-To: <87zgo4hrjq.fsf@gmx.de> (Michael Albinus's message of "Mon, 10 Jan 2022 10:24:25 +0100")

On 10 Jan 2022, Michael Albinus wrote:
>>> I'm not sure that this is always the case. For Tramp, I'm 
>>> happy if
>>> people refer to the Emacs repo files; sync with the upstream 
>>> package
>>> is something contributors don't need to worry about. We shall 
>>> keep
>>> the barrier low.
>>
>> Hmmm.  In that case, should Tramp be listed in the "Externally
>> maintained packages" section of admin/MAINTAINERS at all?
>
>It is OK to be listed there. I just don't want to *urge* people 
>to use
>the Tramp repo, unless it is needed.

Hmm, but how will they know whether it is needed?  Perhaps the new 
"Notes" field in the Tramp entry could give some guidance on that.

The original goal of this change was to provide guidance to 
contributors who might otherwise waste time doing the wrong thing. 
For example, they might fail to check upstream to see if a bug has 
already been fixed there, or is being discussed there; or they 
might send a contribution to Emacs when really it should be sent 
somewhere else; etc.

So if there are circumstances in which contributors should worry 
about these possibilities for Tramp, then the Tramp entry in that 
file should explain what those circumstances are -- this is, after 
all, what the entry is for :-).

>And the information about Tramp's bug tracker and backward 
>compatibility (just pushed to the repo) makes it worthwile.

Got it.  So it sounds like the "Notes" field should give some 
advice about checking the upstream sources and bug tracker first, 
when trying to find out if a bug is already known/addressed.  And 
if you're happy to accept patches against the sources shipped in 
Emacs, even when those sources are slightly out-of-date with 
respect to what you have upstream, then "Notes" can say that too.

Thoughts?

Best regards,
-Karl



  reply	other threads:[~2022-01-10 16:20 UTC|newest]

Thread overview: 32+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2021-12-04 21:14 Improving documentation of Org Mode integration into Emacs Karl Fogel
2021-12-04 21:18 ` Karl Fogel
2021-12-04 22:09 ` [External] : " Drew Adams
2021-12-05  5:16 ` Stefan Monnier
2021-12-05  6:38 ` Eli Zaretskii
2022-01-03  5:05   ` Karl Fogel
2022-01-03  5:44     ` Stefan Monnier
2022-01-05  3:09       ` Karl Fogel
2022-01-05 13:48         ` Eli Zaretskii
2022-01-05 14:17           ` Michael Albinus
2022-01-05 14:26             ` Eli Zaretskii
2022-01-06 12:40               ` Michael Albinus
2022-01-06 13:58                 ` Eli Zaretskii
2022-01-07 10:41                   ` Protesilaos Stavrou
2022-01-09 22:34           ` Karl Fogel
2022-01-10  8:46             ` Michael Albinus
2022-01-10  9:03               ` Michael Albinus
2022-01-10  9:13                 ` Karl Fogel
2022-01-10  9:17                   ` Michael Albinus
2022-01-10 11:01                   ` Robert Pluim
2022-01-10 16:10                     ` Karl Fogel
2022-01-10  9:06               ` Karl Fogel
2022-01-10  9:24                 ` Michael Albinus
2022-01-10 16:20                   ` Karl Fogel [this message]
2022-01-10 18:24                     ` Eli Zaretskii
2022-01-11  7:49                       ` Michael Albinus
2022-01-10 18:14             ` Eli Zaretskii
2022-01-10 19:08               ` Karl Fogel
2022-01-03  8:52     ` Michael Albinus
2022-01-03 12:06     ` Protesilaos Stavrou
2022-01-03 13:31     ` Eli Zaretskii
2022-01-03 20:45     ` Rudolf Adamkovič

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=87ilurftpw.fsf@red-bean.com \
    --to=kfogel@red-bean.com \
    --cc=emacs-devel@gnu.org \
    --cc=kyle@kyleam.com \
    --cc=michael.albinus@gmx.de \
    /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).