[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Win32 GnuTLS DLL installer?

From: Ted Zlatanov
Subject: Re: Win32 GnuTLS DLL installer?
Date: Fri, 22 Sep 2017 08:44:44 -0400
User-agent: Gnus/5.13 (Gnus v5.13) Emacs/26.0.50 (gnu/linux)

On Thu, 21 Sep 2017 22:08:42 +0100 address@hidden (Phillip Lord) wrote: 

PL> To me, the sane "update" proceedure is "install a new version of
PL> emacs". If you want updating outside of that there are more holisitic
PL> solutions like chocolaty.

OK, let's focus on that then, and treat new DLL drops as a revision
increment, 25.3-2 for instance. Then the problem is reduced to building,
testing, and supporting a single version (which we already do). On the
user side, either an automated function or a manual "prominent button"
command will check that version and maybe optionally launch into a
package update.

On Thu, 21 Sep 2017 22:13:31 +0100 address@hidden (Phillip Lord) wrote: 

PL> Ted Zlatanov <address@hidden> writes:

>> When a GitLab server is available, maybe we can set up a W32 build slave
>> to build and test these binaries.

PL> That would be a joy. At the moment, the binaries have minimal testing.

I also want to note that Docker images (ubuntu for instance) can run on
W32, so we can suggest that. That may work for some Emacs users and
reduce their dependence on W32.

PL> We don't have a good test suite, though, not for binaries. For example,
PL> if I don't add libXpm into the zip file, the tests will probably
PL> succeed, Emacs will run, but it will look very ropey.

OK, we'll plan to work on that.

On Fri, 22 Sep 2017 10:29:02 +0300 Eli Zaretskii <address@hidden> wrote: 

EZ> If we are willing to disregard the QA in these libraries for the
EZ> Windows users, then I submit that we should not consider seriously any
EZ> security aspects of the Windows binaries.  We are in effect leaving it
EZ> to the users to discover the problems and report them.

I don't think anyone is suggesting disregarding QA. We should work on
automating the QA process. Meanwhile we should do what we reasonably can
to support our users: focus on a single package and implement a way for
them to check that they are up to date.

(The Emacs model has been "users discover the problems and report them"
for many years. The notions of a test suite and CI are relatively very
recent and the test coverage is far from perfect. I think we'll only get
better at QA automation as our needs and capabilities evolve.)


reply via email to

[Prev in Thread] Current Thread [Next in Thread]