From: phillip.lord@russet.org.uk
To: Eli Zaretskii <eliz@gnu.org>
Cc: emacs-devel@gnu.org
Subject: Re: Emacs 27.1 Windows Binaries -- testing wanted
Date: Sat, 22 Aug 2020 13:52:22 +0100 [thread overview]
Message-ID: <8373b3870aaea52590ee392bd6ff1ca9@russet.org.uk> (raw)
In-Reply-To: <83eenz9bir.fsf@gnu.org>
On 2020-08-22 12:15, Eli Zaretskii wrote:
>> Date: Sat, 22 Aug 2020 11:53:54 +0100
>> From: phillip.lord@russet.org.uk
>> Cc: emacs-devel@gnu.org
>> I do not want to display all the output, I want to know what it
>> should be. And I don't care about the output from things that work
>> as expected only things that do not. All of this is what ert is
>> designed for. I might like to tweak the output a little, but as ert
>> doesn't have a pluggable interface, that's harder.
>
> I'm not talking about using ert or not, I'm talking about determining
> which of the features should check out and which shouldn't. Are you
> going to edit w32-features.el by hand each time you add or remove an
> optional library from the build? Or will the list of the features
> which should check out be constructed automagically somehow?
It would be manual. The list of features changes rarely enough that it's
hard to automate this and know that it will work. The automation is as
likely to break as a manual system, as a release is not routine enough
(for instance, you slightly broke my build script by updating the
version number on Emacs-27 before I had done the windows build -- not a
complaint, but Emacs releases are not routine).
If I think back to the bugs with Emacs binary releases, this would have
stopped only a few: harfbuzz and svg failure in this release. It would
not have prevented missing dependencies (I have missed all of harfbuzz,
lcms and libjansson till late in the day), nor the failed optimization
or stripping. But, it would stop regressions of all of those, assuming I
can work out how to test for them all.
> If the latter, I didn't see you describe how will that happen. If the
> former, it means a file in the distribution will depend on the details
> of how you build the official binaries, which could be different from
> what end-users do on their systems (those who build their own Emacs),
> so the tests will fail for them, AFAIU.
That is true with all of our tests, I think. json parsing is tested by
make check and it will not work on msys2 if the dependencies are not
installed. In this case, I am not suggesting adding ert tests to make
check, but a manually run test specifically for understanding the
features of a binary build. I am guessing anyone running this would be
understand what they are doing enough to know why. And I will document
the entry function.
> It might also mean problems in merging from the release branch to
> master,
> e.g. if we remove some optional library from master that is still being
> used on the release
> branch.
That problem is there anyway in build-deps.py and it is worse there
since it will break a release rather than fail to test it. And I think
for configure.ac also no?
> I guess what I'm saying is that I don't yet see the overall picture of
> how this is supposed to work. Apologies if I'm missing something.
I think it is worth the discussion -- releases are far apart and it
takes a degree of insight to get this right.
Phil
next prev parent reply other threads:[~2020-08-22 12:52 UTC|newest]
Thread overview: 64+ messages / expand[flat|nested] mbox.gz Atom feed top
2020-08-18 2:05 Emacs 27.1 Windows Binaries -- testing wanted Jonathan Mitchell
2020-08-18 4:55 ` Eli Zaretskii
2020-08-18 6:56 ` phillip.lord
2020-08-18 7:11 ` Jonathan Mitchell
2020-08-18 15:34 ` Eli Zaretskii
2020-08-18 15:57 ` Óscar Fuentes
2020-08-18 16:33 ` Eli Zaretskii
2020-08-18 16:48 ` Óscar Fuentes
2020-08-18 17:05 ` Eli Zaretskii
2020-08-18 19:32 ` Stefan Monnier
2020-08-19 2:32 ` Eli Zaretskii
2020-08-19 13:10 ` Stefan Monnier
2020-08-19 15:06 ` Eli Zaretskii
2020-08-19 15:30 ` Stefan Monnier
2020-08-19 16:39 ` Eli Zaretskii
2020-08-18 17:20 ` phillip.lord
2020-08-18 18:11 ` Daniel Brooks
2020-08-18 18:58 ` Eli Zaretskii
2020-08-18 19:54 ` Daniel Brooks
2020-08-18 18:15 ` Eli Zaretskii
2020-08-21 19:16 ` phillip.lord
2020-08-21 19:44 ` Eli Zaretskii
2020-08-21 21:37 ` phillip.lord
2020-08-21 22:53 ` Drew Adams
2020-08-22 6:46 ` Eli Zaretskii
2020-08-22 10:30 ` phillip.lord
2020-08-24 9:28 ` Robert Pluim
2020-08-24 10:40 ` Eli Zaretskii
2020-08-24 12:11 ` Robert Pluim
2020-08-24 15:14 ` Stefan Monnier
2020-08-24 15:48 ` Eli Zaretskii
2020-08-24 16:49 ` Stefan Monnier
2020-08-24 17:06 ` phillip.lord
2020-08-24 17:10 ` Eli Zaretskii
2020-08-24 18:35 ` Stephen Leake
2020-08-24 18:54 ` Stefan Monnier
2020-08-24 17:01 ` phillip.lord
2020-08-21 20:15 ` Alan Third
2020-08-21 21:56 ` phillip.lord
2020-08-22 6:37 ` Eli Zaretskii
2020-08-22 10:21 ` phillip.lord
2020-08-22 10:40 ` Eli Zaretskii
2020-08-22 10:53 ` phillip.lord
2020-08-22 11:15 ` Eli Zaretskii
2020-08-22 12:52 ` phillip.lord [this message]
2020-08-22 13:08 ` Eli Zaretskii
2020-08-22 13:53 ` phillip.lord
2020-08-22 14:35 ` Eli Zaretskii
2020-08-22 15:13 ` phillip.lord
2020-08-22 15:19 ` Eli Zaretskii
2020-08-22 17:28 ` phillip.lord
2020-08-22 17:32 ` Eli Zaretskii
2020-08-22 20:18 ` phillip.lord
2020-08-22 20:32 ` Stefan Monnier
2020-08-23 21:19 ` phillip.lord
2020-08-23 21:57 ` Stefan Monnier
2020-08-23 5:36 ` Eli Zaretskii
2020-08-23 7:53 ` phillip.lord
-- strict thread matches above, loose matches on Subject: below --
2020-08-10 23:00 Emacs 27.1 released Nicolas Petton
2020-08-12 12:01 ` phillip.lord
2020-08-15 17:49 ` Emacs 27.1 Windows Binaries -- testing wanted phillip.lord
2020-08-15 17:54 ` Eli Zaretskii
2020-08-15 18:38 ` Stephen Leake
2020-08-15 19:57 ` Alan Third
2020-08-17 4:44 ` Sivaram Neelakantan
2020-08-17 23:24 ` Tak Kunihiro
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
List information: https://www.gnu.org/software/emacs/
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=8373b3870aaea52590ee392bd6ff1ca9@russet.org.uk \
--to=phillip.lord@russet.org.uk \
--cc=eliz@gnu.org \
--cc=emacs-devel@gnu.org \
/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 public inbox
https://git.savannah.gnu.org/cgit/emacs.git
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).