Re: emacs-28 b8b2dd1: Update to Org 9.5.1-11-g96d91b

Re: emacs-28 b8b2dd1: Update to Org 9.5.1-11-g96d91b

[Michael Albinus]

kyle@kyleam.com (Kyle Meyer) writes:

> branch: emacs-28
> commit b8b2dd17c57b73357cae229e010138fd2352a46f
> Author: Kyle Meyer <kyle@kyleam.com>
> Commit: Kyle Meyer <kyle@kyleam.com>
>
>     Update to Org 9.5.1-11-g96d91b
> ---
>  doc/misc/org.org         | 12 ++++++++++++
>  etc/refcards/orgcard.tex |  2 +-
>  lisp/org/oc-csl.el       |  3 ++-
>  lisp/org/oc.el           | 43 ++++++++++++++++++++++---------------------
>  lisp/org/org-table.el    |  2 +-
>  lisp/org/org-version.el  |  4 ++--
>  lisp/org/ox.el           |  3 +++
>  7 files changed, 43 insertions(+), 26 deletions(-)

This fails:

--8<---------------cut here---------------start------------->8---
$ make -C test org-tests
make: Entering directory '/usr/local/src/emacs-28/test'
make[1]: Entering directory '/usr/local/src/emacs-28/test'
  GEN      lisp/org/org-tests.log
Running 1 tests (2021-11-28 16:11:21+0100, selector `(not (or (tag :unstable) (tag :nativecomp)))')
Test org-package-version backtrace:
  signal(ert-test-failed (((should (equal (version-to-list (org-releas
  ert-fail(((should (equal (version-to-list (org-release)) (cdr (assq
  (if (unwind-protect (setq value-7 (apply fn-5 args-6)) (setq form-de
  (let (form-description-9) (if (unwind-protect (setq value-7 (apply f
  (let ((value-7 'ert-form-evaluation-aborted-8)) (let (form-descripti
  (let* ((fn-5 #'equal) (args-6 (condition-case err (let ((signal-hook
  (let ((lexical-binding t)) (let* ((fn-0 #'require) (args-1 (conditio
  (closure (t) nil (let ((lexical-binding t)) (let* ((fn-0 #'require)
  ert--run-test-internal(#s(ert--test-execution-info :test #s(ert-test
  ert-run-test(#s(ert-test :name org-package-version :documentation "T
  ert-run-or-rerun-test(#s(ert--stats :selector (not (or (tag :unstabl
  ert-run-tests((not (or (tag :unstable) (tag :nativecomp))) #f(compil
  ert-run-tests-batch((not (or (tag :unstable) (tag :nativecomp))))
  ert-run-tests-batch-and-exit((not (or (tag :unstable) (tag :nativeco
  eval((ert-run-tests-batch-and-exit '(not (or (tag :unstable) (tag :n
  command-line-1(("-L" ":." "-L" "./../../elpa/packages/url-http-ntlm/
  command-line()
  normal-top-level()
Test org-package-version condition:
    (ert-test-failed
     ((should
       (equal
	(version-to-list ...)
	(cdr ...)))
      :form
      (equal
       (9 5 1)
       (9 5))
      :value nil :explanation
      (proper-lists-of-different-length 3 2
					(9 5 1)
					(9 5)
					first-mismatch-at 2)))
   FAILED  1/1  org-package-version (0.000878 sec)

Ran 1 tests, 0 results as expected, 1 unexpected (2021-11-28 16:11:21+0100, 0.109542 sec)

1 unexpected results:
   FAILED  org-package-version
--8<---------------cut here---------------end--------------->8---

Best regards, Michael.

Re: emacs-28 b8b2dd1: Update to Org 9.5.1-11-g96d91b

[Kyle Meyer]

Michael Albinus writes:

> This fails:
>
> --8<---------------cut here---------------start------------->8---
> $ make -C test org-tests

Sorry about that.  I see Stefan has already fixed it (thanks), but I
will port that change back to the Org repo, make sure to check in the
future, and look into adding a similar check to Org's test suite so that
the issue is caught earlier.

Re: emacs-28 b8b2dd1: Update to Org 9.5.1-11-g96d91b

[Michael Albinus]

Kyle Meyer <kyle@kyleam.com> writes:

Hi Kyle,

> Sorry about that.  I see Stefan has already fixed it (thanks), but I
> will port that change back to the Org repo, make sure to check in the
> future, and look into adding a similar check to Org's test suite so that
> the issue is caught earlier.

Thanks!

Btw, Org's test suite is huge IIRC. Would it make sense to merge this
also to Emacs? At least the CI/CD test runs on hydra and emba could use
them, I believe.

(This would be something for master only, I believe)

Best regards, Michael.

Re: emacs-28 b8b2dd1: Update to Org 9.5.1-11-g96d91b

[Kyle Meyer]

Michael Albinus writes:

> Btw, Org's test suite is huge IIRC. Would it make sense to merge this
> also to Emacs? At least the CI/CD test runs on hydra and emba could use
> them, I believe.

Yes, I think that makes sense, though I probably won't have time to look
into it very soon.  Aside from potential code adjustments that may be
necessary, I suppose copyright assignments need to be checked.  Most of
the test files list individuals as copyright holders.  At a glance, I'm
not confident that all the authors have paperwork on file.

Org tests in Emacs (was: emacs-28 b8b2dd1: Update to Org 9.5.1-11-g96d91b)

[Michael Albinus]

Kyle Meyer <kyle@kyleam.com> writes:

Hy Kyle,

>> Btw, Org's test suite is huge IIRC. Would it make sense to merge this
>> also to Emacs? At least the CI/CD test runs on hydra and emba could use
>> them, I believe.
>
> Yes, I think that makes sense, though I probably won't have time to look
> into it very soon.  Aside from potential code adjustments that may be
> necessary, I suppose copyright assignments need to be checked.  Most of
> the test files list individuals as copyright holders.  At a glance, I'm
> not confident that all the authors have paperwork on file.

I see. Maybe we could start iteratively? That means, adapt the test
files where's no copyright problem, and bring them to Emacs git. For the
other files, we will contact the authors, and bring them to Emacs case
by case, when the copyright has been fixed.

If needed, I could help you. Just tell me.

Btw, you could runn all tests under test/lisp/org by

make -C test check-lisp-org

And the dust on emba.gnu.org settled. That is, whenever there is a
change in either lisp/org/*.el or test/lisp/org/*.el, all tests under
test/lisp/org/*.el will run automatically, as regression test. An extra
bonus, isn't it?

See <https://emba.gnu.org/emacs/emacs/-/pipelines>

Best regards, Michael.

Current status of emba.gnu.org?

[Stefan Kangas]

Michael Albinus <michael.albinus@gmx.de> writes:

> And the dust on emba.gnu.org settled. [snip]
>
> See <https://emba.gnu.org/emacs/emacs/-/pipelines>

BTW, just because I'm curious, what is the current status of our
automated tests on emba.gnu.org?

Are we nearing a situation where we could start relying on it for things
like sending automated messages to committers when they introduce
regressions?  That would be a real time-saver.

Oh, and thanks again for working on this.

Re: Current status of emba.gnu.org?

[Michael Albinus]

Stefan Kangas <stefan@marxist.se> writes:

Hi Stefan,

> BTW, just because I'm curious, what is the current status of our
> automated tests on emba.gnu.org?

They are up and running. There will still be some optimizations, but
that's minor.

> Are we nearing a situation where we could start relying on it for things
> like sending automated messages to committers when they introduce
> regressions?  That would be a real time-saver.

We could start to implement this. It won't be trivial, though. The Emacs
git repository on emba is a mirror from savannah. But it is not synced
automatically, because we run the community edition of Gitlab only,
which does not support pull mirroring.

Instead, we have a cronjob on emba.gnu.org, which pulls all changes from
savannah every 5 minutes. So a new pipeline on emba could start
triggered by several independent commits pushed to Emacs git on
savannah. In case the pipeline (respective one of its jobs) fails, we
don't know who is the author of the problematic commit. So all commit
authors would get a notification email, even if not guilty.

I don't know how relevant this is, most commits are performed with more
than 5 minutes in between. Let's see how it goes.

> Oh, and thanks again for working on this.

Well, first I need to investigate how to trigger such emails with
Gitlab. If somebody know, pls share this knowledge.

Best regards, Michael.

Re: Current status of emba.gnu.org?

[Stefan Kangas]

Michael Albinus <michael.albinus@gmx.de> writes:

> Instead, we have a cronjob on emba.gnu.org, which pulls all changes from
> savannah every 5 minutes. So a new pipeline on emba could start
> triggered by several independent commits pushed to Emacs git on
> savannah. In case the pipeline (respective one of its jobs) fails, we
> don't know who is the author of the problematic commit. So all commit
> authors would get a notification email, even if not guilty.

I think this is an acceptable limitation, and an improvement over what
we have now.

BTW, is there any reason not to check more often than every 5 minutes?
For example, could we just go very aggressive and check every minute or
two?

Re: Current status of emba.gnu.org?

[Michael Albinus]

Stefan Kangas <stefan@marxist.se> writes:

Hi Stefan,

>> Instead, we have a cronjob on emba.gnu.org, which pulls all changes from
>> savannah every 5 minutes. So a new pipeline on emba could start
>> triggered by several independent commits pushed to Emacs git on
>> savannah. In case the pipeline (respective one of its jobs) fails, we
>> don't know who is the author of the problematic commit. So all commit
>> authors would get a notification email, even if not guilty.
>
> I think this is an acceptable limitation, and an improvement over what
> we have now.
>
> BTW, is there any reason not to check more often than every 5 minutes?
> For example, could we just go very aggressive and check every minute or
> two?

This seems to be the Gitlab default, see
<https://emba.gnu.org/help/administration/instance_limits.md#pull-mirroring-interval>:

--8<---------------cut here---------------start------------->8---
The minimum time between pull refreshes defaults to 300 seconds (5
minutes).
--8<---------------cut here---------------end--------------->8---

Sounds like we could change it. I'm adding Ted to Cc, he has set up
emba.gnu.org.

Best regards, Michael.

Re: Current status of emba.gnu.org?

[Stefan Monnier]

> BTW, is there any reason not to check more often than every 5 minutes?

FWIW, I wouldn't try to pull more frequently unless there's a clear and
concrete need for it.

OTOH we could subscribe to the commit-diffs and pull from the
.procmailrc instead of doing it from a cron job, so we don't need
to poll at all.


        Stefan

Re: Current status of emba.gnu.org?

[Michael Albinus]

Stefan Monnier <monnier@iro.umontreal.ca> writes:

Hi Stefan,

>> BTW, is there any reason not to check more often than every 5 minutes?
>
> FWIW, I wouldn't try to pull more frequently unless there's a clear and
> concrete need for it.

I agree. Let's start with the default settings.

> OTOH we could subscribe to the commit-diffs and pull from the
> .procmailrc instead of doing it from a cron job, so we don't need
> to poll at all.

We have also another option: use a push mirror. That is, emacs.git on
savannah pushes any change to the repository on emba, when it receices
it. We might keep this in mind if needed.

(I haven't configured such a mirror yet, but I believe it must be possible)

>         Stefan

Best regards, Michael.