From: Ihor Radchenko <yantar92@posteo.net>
To: Max Nikulin <manikulin@gmail.com>
Cc: emacs-orgmode@gnu.org, Bastien Guerry <bzg@gnu.org>
Subject: Re: Worg: issue with org-tools page
Date: Sun, 06 Aug 2023 15:08:16 +0000 [thread overview]
Message-ID: <87tttcryxr.fsf@localhost> (raw)
In-Reply-To: <ef628e66-cfc5-a5d8-38ed-a46955138a7b@gmail.com>
Max Nikulin <manikulin@gmail.com> writes:
>> I am not sure why it would be useful to limit the number of errors to
>> anything other than 0/infinity.
>
> You have agreed that aborting of upload on any error may be
> disappointing when the error was introduced by another person.
This will not happen now.
See https://git.sr.ht/~bzg/worg/tree/master/item/.build.yml
The error is only reported after "upload" via "check" task.
> If there are dozens of failures then something serious has happened
> either with Org or with Worg and it is a reason to not upload partial
> results.
>
> I believe that list of 5-10 failed files is suitable for notification
> failure (e-mail, instant messaging, etc.).
Even a single failed file should trigger e-mail notification.
As for dozens of failures caused by something serious, I do hope that
Org commiters are careful enough. WORG uses bugfix version of Org where
we already push with care, when we are confident that things should not
break even theoretically. And if the large failures are caused by WORG
commit, it should be a commit either touching the build system or basic
WORG includes - such commits should be taken with care anyway.
In summary, I do not think that we should be concerned about downtime
caused by accidental and _also very serious_ issue caused by careless
commit. If we do encounter such scenarios, it will be a sign that we
should switch to a proper testing/production website builds; not trying
to re-invent the wheel with ad-hoc build script solutions.
>> Note that I just pushed an alternative (but very similar) change in
>> https://git.sr.ht/~bzg/worg/commit/b38a1f08
>
> It fails on first error. I find a report containing several errors much
> more helpful for figuring out what has actually happened. On the other
> hand there should be a strong reason to read all errors when there are
> hundreds one.
You are right. I will see what I can do to throw exit only at the end,
showing all the errors.
> P.S. You have not documented that your approach abuses --debug-init
> standard Emacs option.
My approach does not abuse --debug-init. The new cmd line argument is --debug.
I have no opinion about which header argument should be used. You can
propose an alternative, if you find something more self-explanatory and
not clashing with the existing Emacs command line args.
--
Ihor Radchenko // yantar92,
Org mode contributor,
Learn more about Org mode at <https://orgmode.org/>.
Support Org development at <https://liberapay.com/org-mode>,
or support my work at <https://liberapay.com/yantar92>
next prev parent reply other threads:[~2023-08-06 15:08 UTC|newest]
Thread overview: 28+ messages / expand[flat|nested] mbox.gz Atom feed top
2023-04-09 15:37 Worg: issue with org-tools page Karl Voit
2023-04-09 16:53 ` Ihor Radchenko
2023-04-09 21:51 ` Karl Voit
2023-04-18 12:29 ` Ihor Radchenko
2023-04-18 13:48 ` Karl Voit
2023-07-29 12:14 ` Ihor Radchenko
2023-07-30 2:57 ` Max Nikulin
2023-07-30 6:40 ` Ihor Radchenko
2023-07-30 7:38 ` Max Nikulin
2023-07-30 9:16 ` Ihor Radchenko
2023-07-31 16:12 ` Max Nikulin
2023-07-31 16:41 ` Ihor Radchenko
2023-08-05 12:14 ` Max Nikulin
2023-08-05 12:23 ` Ihor Radchenko
2023-08-06 11:31 ` Max Nikulin
2023-08-06 15:08 ` Ihor Radchenko [this message]
2023-08-09 7:44 ` Ihor Radchenko
2023-08-09 10:35 ` Max Nikulin
2023-08-04 10:21 ` Bastien Guerry
2023-08-05 7:12 ` Ihor Radchenko
2023-08-05 8:50 ` Bastien Guerry
2023-08-05 11:06 ` Ihor Radchenko
2023-08-05 18:07 ` Bastien Guerry
2023-08-06 6:34 ` Ihor Radchenko
2023-08-06 15:17 ` Bastien Guerry
2023-08-07 13:46 ` Ihor Radchenko
2023-08-07 14:26 ` Bastien Guerry
2023-08-10 8:45 ` Ihor Radchenko
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
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=87tttcryxr.fsf@localhost \
--to=yantar92@posteo.net \
--cc=bzg@gnu.org \
--cc=emacs-orgmode@gnu.org \
--cc=manikulin@gmail.com \
/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 external index
https://git.savannah.gnu.org/cgit/emacs.git
https://git.savannah.gnu.org/cgit/emacs/org-mode.git
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.