<div dir="ltr"><br><br><div class="gmail_quote"><div dir="ltr">On Thu, 17 May 2018 at 04:25 Paul Moore <<a href="mailto:p.f.moore@gmail.com">p.f.moore@gmail.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">On 17 May 2018 at 04:46, Alex Walters <<a href="mailto:tritium-list@sdamon.com" target="_blank">tritium-list@sdamon.com</a>> wrote:<br>
>> 1. Producing binaries (to the quality we normally deliver - I'm not<br>
>> talking about auto-built binaries produced from a CI system) is a<br>
>> chunk of extra work for the release managers.<br>
><br>
> This is actually the heart of the reason I asked the question.  CI tools are fairly good now.  If the CI tools could be used in such a way to make the building of binary artifacts less of a burden on the release managers, would there be interest in doing that, and in the process, releasing binary artifact installers for all security update releases.<br>
><br>
> My rationale for asking if its possible is... well.. security releases are important, and it's hard to ask Windows users to install Visual Studio and build python to use the most secure version of python that will run your python program.  Yes there are better ideal solutions (porting your code to the latest and greatest feature release version), but that’s not a zero burden option either.<br>
><br>
> If CI tools just aren't up to the task, then so be it, and this isn't something I would darken -ideas' door with.<br>
<br>
I honestly don't know if we're at a point where an auto-built security<br>
release would be sufficient and/or useful. That's mostly a question<br>
for the release manager(s). One sticking point might be that I believe<br>
the Windows installers (at least) are signed, and only the release<br>
managers have the signing key. It's probably *not* OK to leave the<br>
security releases unsigned ;-) So there would be a key management<br>
issue to address there.<br></blockquote><div><br></div><div>If I understand things correctly, our planned migration to VSTS will include eventually automating the signing of the Windows releases so that part wont be an issue (which are currently signed manually be Steve).<br></div></div></div>