>Just my 2 cents… instead of dropping them altogether, would it be an
>acceptable middle ground to show a message like:
>
>"This diff is very big, if you wish to load it [click here]"

GitHub also takes a similar approach, though they just refuse to load it
at all and you'd have to view raw instead.  Raw files should load
faster, I suppose, as it's not encumbered with markups.

I think viewing big diffs like this (more than 100000 lines) can be
disruptive in addition to taking long time to load, so it makes sense to
have a warning like that.

This merge request has been superseded by another (22132).

https://gitlab.alpinelinux.org/alpine/aports/-/merge_requests/22132

I also noticed some problems with this patch:

- The ARM builds failed, though I don't know the reason.  I will exclude
   those architectures from the next patch if needed.
- The build does not run tests yet.  I'm not clear how the tests are
   run, and the upstream maintainer said he would test it himself.
- `rc-service dictd start` isn't working yet, because there is no
   dictionaries in `/usr/share/dict/` yet.  If you want to test it,
   you can download a dictionary from a repo I created [0].

[0]: https://github.com/Huy-Ngo/dictd-dictionaries/tree/ubuntu-dicts/build

This merge request was done via [mailing list][0], done to address
change requests in [!21866][1].  Because of the current state of the
mirror feature [2], please close the previous merge request in favor of
this one.

[0]: https://lists.alpinelinux.org/~alpine/aports/patches/3540
[1]: https://gitlab.alpinelinux.org/alpine/aports/-/merge_requests/21866
[2]: https://lists.alpinelinux.org/~alpine/devel/%3CCBIBXMCZAEGA.1AI1ROGFMRV0Z%40taiga%3E

https://sourceforge.net/projects/dict/
Client/server software and tools supporting DICT protocol (RFC 2229)
---
 testing/dictd/APKBUILD     | 36 +++++++++++++++++
 testing/dictd/colorit.conf | 32 +++++++++++++++
 testing/dictd/dict.conf    |  6 +++
 testing/dictd/dictd.conf   | 14 +++++++
 testing/dictd/dictd.initd  | 80 ++++++++++++++++++++++++++++++++++++++
 5 files changed, 168 insertions(+)
 create mode 100644 testing/dictd/APKBUILD
 create mode 100644 testing/dictd/colorit.conf
 create mode 100644 testing/dictd/dict.conf
 create mode 100644 testing/dictd/dictd.conf
 create mode 100644 testing/dictd/dictd.initd
[message trimmed]

> Comments and feedback submitted on the GitLab merge request, or sent to
> the email thread, will be mirrored bidirectionally between both mediums

For some reason, the feedback on GitLab was not sent back to the mailing list
in my case.  A patch I sent to the mailing list [0] received two comments
on GitLab [1], but no replies are found on the mailing list.

[0]: https://lists.alpinelinux.org/~alpine/aports/patches/3535
[1]: https://gitlab.alpinelinux.org/alpine/aports/-/merge_requests/21866

Sorry because I forgot to CC the mailing list, and effectively moved the
discussion to private.  Summary of my suggestions:

- Only yearly will have suffix .0.0 and therefore one can `grep \.0\.0`
   to find the yearly releases
- We can name major releases after cheeses, for example, `2022.0.0-alpkaese`,
   so the name is visibly longer with alphabetic characters, thus more
   distinguishible.
   Additionally, one can `grep [a-z]` to find them.  Cheese names are a
   bit hard to remember IMO, or mabye it's just an cheese-uncultured me.

https://sourceforge.net/projects/dict/
Client/server software and tools supporting DICT protocol (RFC 2229)
---
 testing/dictd/APKBUILD     | 37 ++++++++++++++++++
 testing/dictd/colorit.conf | 32 +++++++++++++++
 testing/dictd/dict.conf    |  6 +++
 testing/dictd/dictd.conf   | 14 +++++++
 testing/dictd/dictd.initd  | 80 ++++++++++++++++++++++++++++++++++++++
 5 files changed, 169 insertions(+)
 create mode 100644 testing/dictd/APKBUILD
 create mode 100644 testing/dictd/colorit.conf
 create mode 100644 testing/dictd/dict.conf
 create mode 100644 testing/dictd/dictd.conf
 create mode 100644 testing/dictd/dictd.initd
[message trimmed]

I think these schemes make sense.  I would propose these two versioning scheme for them:

- Yearly releases: $YEAR.0.0
- Weekly releases: $YEAR.$MONTH.$WEEK

Where $WEEK is 0-indexed nth of the month.

On 07.05.2021 17:38, Simon Ser wrote:
>If you have time, also try to run python-emailthreads directly on the
>message.

I have tried, and the messages was parsed just fine, so I think I
shouldn't file an issue in that repository.  In fact, the [mail
archive][0] also displayed the message correctly.  It is only the patch
view that has the problem.

[0]: https://lists.sr.ht/~cnx/ipwhl-devel/%3C20210429050645.9626-1-huyngo%40disroot.org%3E