[QUESTION] I need your opinion / view - Should we test Emacs before releasing it?

[mpsq]

Sometimes upstream has bugs, sometimes upstream has changes that break popular libraries. This is what you would expect when running a development version of Emacs. But maybe it does not have to be like that, maybe we could "test" Emacs first in CI and make sure it is "valid".

Solutions

1 - 🎉

We could "test" Emacs simply by pulling a popular minimal distro, doom-emacs and compiling it. If everything goes as intended, then we can release the new version, otherwise we cancel the current pipeline. Vanilla Doom runs very popular packages that people are likely to use, it could be a good "test".

This would potentially jeopardize the very idea of this package: running a super fresh version of Emacs. See solution 2 or 3 if that is a concern.

2 - 🚀

Same as 1 but in a new package instead: we keep everything as is for "emacs-gcc-wayland-devel-bin" and create a new distribution pipeline with a corresponding package on AUR. This would satisfy both worlds.

3 - 👀

We don't care, don't change things.

4 - ❤️

Solution coming from @cosmic-goat's comment, maintaining a set of patches that "undo" disruptive changes while keeping Emacs up to date.

Feedback

Please don't hesitate to vote / comment / suggest other solutions, etc.

[aarchangel64]

Perhaps another option might be to revert certain breaking commits (presumably in a new package?). For example I 'fixed' the issues with define-obsolete-function-alias for my doom-emacs install by adding

git revert --no-edit 32c6732d16

to prepare() within the PKGBUILD for emacs-pgtk-native-comp-git.

This would somewhat solve the issue of having the latest devel emacs, since the newest upstream commits could be pulled first and then any reverted commits could be applied on top (as long as no major conflicts arise, at least).

[mpsq]

@Cosmic-Goat thanks for your feedback, makepkg also has mechanisms to maintain patches, this is a good option too, I will update the first comment.

[chaoky]

I think you would have use to spacemacs, it's more popular and I because doom is so minimal, I've never experienced any issues with doom's default packages.

[appetrosyan]

I think that the experimental branches are experimental for a reason. Testing would be nice, but cancelling the pipeline might not be necessary. After all, it might work for me, 'cause one of the misbehaving packages isn't in my configuration and I might want to upgrade. Maybe add the test result as a part of the git tag, e.g. 28.*.UNSTABLE and 28.*.STABLE, depending on the test results.

[Gerry2k5]

As a user, I want the latest and greatest; but as a coder, I want stable, reliable and reproducible;

I think that's solution 2 but 4 suits it as well;

My own preference is for solution 2 (I like to see '-git' at the end of the names of packages which are undergoing frequent changes)