Re: Worg: issue with org-tools page

[Ihor Radchenko]

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>