GNU bug report logs - #32676
[PATCH] Add option to highlight the 'next-error' error message

Previous Next

Full log

View this message in rfc822 format

From: Kyle Meyer <kyle <at> kyleam.com>
To: Kévin Le Gouguec <kevin.legouguec <at> gmail.com>, Juri Linkov <juri <at> linkov.net>
Cc: 32676 <at> debbugs.gnu.org
Subject: bug#32676: Updating Org for 27.2
Date: Mon, 09 Nov 2020 23:10:10 -0500

Kévin Le Gouguec writes:

> Juri Linkov <juri <at> linkov.net> writes:
>
>> Do you know if the synchronization process will override the changes
>> made in master?  If I fix an issue in bug#44524 and will commit the fix
>> to Emacs master in the subdir emacs/lisp/org, won't the synchronization
>> process of the recent Org version override my fix?
>
> The document I referred to covers this situation (§ Backporting changes
> from upstream Emacs), but I don't know if there are automated checks in
> place to make sure no commits are missed.

No, there's not.  I check at least once a week and propagate (or
otherwise deal with) any commits from the Emacs repo that touch Org
files.  I have a fairly dumb system for it, but I think it's worked well
enough [*] in terms of catching commits.  It's essentially just a
command (described in the document you're referring to, I believe) that
does

    git log <last commit ported>..<branch> -- <org files>

to get a list of commits that go into an Org checklist.  The
occasionally time consuming part is dealing with the conflicts and with
commits on Emacs's end that don't maintain compatibility with the
minimal Emacs version that Org supports.

  [*] That's not to say that I think the current system of porting and
      then syncing via manual copying is a good one.  I look forward to
      $something better, but in the meantime things need to stay afloat.

At any rate, since 2015, I have notes on all the commits considered.  I
moved these from my personal notes repo to a dedicated repo in 2019.  In
case it's helpful, I've just pushed it to
<https://git.kyleam.com/orgmode-backport-notes/>.

If you're worried a commit didn't get considered, you can first check in
the Org repo with

  $ git log --grep=<full commit ID from Emacs repo>

since the commit messages use a consistent format that includes the full
hash.  As an example:

    Backport commit dd16e46bb from Emacs

    ; Prefer https to http in more URLs
    dd16e46bb9d0099baea06d780ad8f62728addc2e
    Stefan Kangas
    Sat Oct 24 20:23:27 2020 +0200

If you don't see it there, you can look into the notes file referred to
above, which should contain some information about why the commit wasn't
applied and what was done instead (with an Org commit reference).  (Now
that it's public, going forward I'll try to make the descriptions a
little less of a brain dump.)

That said...

> IIUC, Org maintainers prefer for changes to be submitted to
> emacs-orgmode <at> gnu.org; they only occasionally dive into
> bug-gnu-emacs <at> gnu.org to look for open Org issues.

...submitting patches on the Org list is of course appreciated,
particularly for things that target Org rather than being part of a
tree-wide cleanup.

Previous Next

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