Home Original page

[Python-Dev] Request for CPython 3.5.3 release

Brett Cannon brett at python.org
Mon Jul 4 18:42:12 EDT 2016 
I should quickly mention that future workflow-related stuff in regards to
https://www.python.org/dev/peps/pep-0512 and the move to GitHub (e.g. CI),
happens on the core-workflow mailing list.

On Mon, 4 Jul 2016 at 15:35 Steve Dower <steve.dower at python.org> wrote:

> On 04Jul2016 0822, Kevin Ollivier wrote:
> > On 7/4/16, 3:32 AM, "Python-Dev on behalf of Sven R. Kunze"
> <python-dev-bounces+kevin-lists=theolliviers.com at python.org on behalf of
> srkunze at mail.de> wrote:
> >>
> >> If you need some assistance here, let me know.
> >
> > I also offer my help with setting up CI and automated builds. :) I've
> actually done build automation for a number of the projects I've worked on
> in the past. In every case, doing so gave benefits that far outweighed the
> work needed to get it going.
>
> It's actually not that much effort - we already have a fleet of
> buildbots that automatically build, test and report on Python's
> stability on a range of platforms. Once a build machine is configured,
> producing a build is typically a single command.
>
> The benefit we get from the heavyweight release procedures is that
> someone trustworthy (the Release Manager) has controlled the process,
> reducing the rate of change and ensuring stability over the end of the
> process. Also that trustworthy people (the build managers) have
> downloaded, built and signed the code without modifying it or injecting
> unauthorised code.
>
> As a result of these, people trust official releases to be correct and
> stable. It's very hard to put the same trust in an automated system (and
> it's a great way to lose signing certificates).
>
> I don't believe the release procedures are too onerous (though Benjamin,
> Larry and Ned are welcome to disagree :) ), and possibly there is some
> more scripting that could help out, but there's really nothing in the
> direct process that we need to do more releases.
>
> More frequent releases would mean more frequent feature freezes and more
> time in "cherry-picking" mode (where the RM has to approve and merge
> each individual fix), which affects all contributors. Shorter cycles
> make it harder to get changes reviewed, merged and tested. This is the
> limiting factor.
>
> So don't worry about offering skills/effort for CI systems (unless you
> want to maintain a few buildbots, in which case read
> https://www.python.org/dev/buildbot/) - go and help review and improve
> some patches instead. The shorter the cycle between finding a need and
> committing the patch, and the more often issues are found *before*
> commit, the more frequently we can do releases.
>
> Cheers,
> Steve
>
>
>
> _______________________________________________
> Python-Dev mailing list
> Python-Dev at python.org
> https://mail.python.org/mailman/listinfo/python-dev
> Unsubscribe:
> https://mail.python.org/mailman/options/python-dev/brett%40python.org
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/python-dev/attachments/20160704/ebf1281e/attachment.html>
More information about the Python-Dev mailing list