[Python-Dev] What is the rationale behind source only releases?

[Ned Deily]

On May 17, 2018, at 04:24, Paul Moore <p.f.moore at gmail.com> wrote:
> On 17 May 2018 at 04:46, Alex Walters <tritium-list at sdamon.com> wrote:
>>> 1. Producing binaries (to the quality we normally deliver - I'm not
>>> talking about auto-built binaries produced from a CI system) is a
>>> chunk of extra work for the release managers.
>> 
>> 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.
>> 
>> 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.
>> 
>> 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.
> 
> I honestly don't know if we're at a point where an auto-built security
> release would be sufficient and/or useful. That's mostly a question
> for the release manager(s). One sticking point might be that I believe
> the Windows installers (at least) are signed, and only the release
> managers have the signing key. It's probably *not* OK to leave the
> security releases unsigned ;-) So there would be a key management
> issue to address there.

IMO, the idea of having either the current CI system or a third party produce binary artifacts for Python releases to be downloadable from python.org is a non-starter for lots of reasons, primarily because of the security risks.

The release team *could* produce those artifacts for releases in security mode and, while it would be some extra work, there are so few of them.  The question is should we.  Once a release moves from bugfix/maintenance mode to security mode, in some ways we are doing a disservice to our users to encourage them to not upgrade to a more recent maintained release.  Release branches in security mode do not get any fixes other than, based on past experience, at most a small number of security issues that might arise.  In particular, security mode release branches receive no platform-support fixes to support newer OS releases and/or newer hardware support and receive no buildbot testing.  Security mode releases today are really for downstream distributors and DIYers who are comfortable building and maintaining their own versions of software.

--
  Ned Deily
  nad at python.org -- []