<div dir="ltr">I should quickly mention that future workflow-related stuff in regards to <a href="https://www.python.org/dev/peps/pep-0512">https://www.python.org/dev/peps/pep-0512</a> and the move to GitHub (e.g. CI), happens on the core-workflow mailing list.</div><br><div class="gmail_quote"><div dir="ltr">On Mon, 4 Jul 2016 at 15:35 Steve Dower <<a href="mailto:steve.dower@python.org">steve.dower@python.org</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">On 04Jul2016 0822, Kevin Ollivier wrote:<br>
> On 7/4/16, 3:32 AM, "Python-Dev on behalf of Sven R. Kunze" <python-dev-bounces+kevin-lists=<a href="mailto:theolliviers.com@python.org" target="_blank">theolliviers.com@python.org</a> on behalf of <a href="mailto:srkunze@mail.de" target="_blank">srkunze@mail.de</a>> wrote:<br>
>><br>
>> If you need some assistance here, let me know.<br>
><br>
> 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.<br>
<br>
It's actually not that much effort - we already have a fleet of<br>
buildbots that automatically build, test and report on Python's<br>
stability on a range of platforms. Once a build machine is configured,<br>
producing a build is typically a single command.<br>
<br>
The benefit we get from the heavyweight release procedures is that<br>
someone trustworthy (the Release Manager) has controlled the process,<br>
reducing the rate of change and ensuring stability over the end of the<br>
process. Also that trustworthy people (the build managers) have<br>
downloaded, built and signed the code without modifying it or injecting<br>
unauthorised code.<br>
<br>
As a result of these, people trust official releases to be correct and<br>
stable. It's very hard to put the same trust in an automated system (and<br>
it's a great way to lose signing certificates).<br>
<br>
I don't believe the release procedures are too onerous (though Benjamin,<br>
Larry and Ned are welcome to disagree :) ), and possibly there is some<br>
more scripting that could help out, but there's really nothing in the<br>
direct process that we need to do more releases.<br>
<br>
More frequent releases would mean more frequent feature freezes and more<br>
time in "cherry-picking" mode (where the RM has to approve and merge<br>
each individual fix), which affects all contributors. Shorter cycles<br>
make it harder to get changes reviewed, merged and tested. This is the<br>
limiting factor.<br>
<br>
So don't worry about offering skills/effort for CI systems (unless you<br>
want to maintain a few buildbots, in which case read<br>
<a href="https://www.python.org/dev/buildbot/" rel="noreferrer" target="_blank">https://www.python.org/dev/buildbot/</a>) - go and help review and improve<br>
some patches instead. The shorter the cycle between finding a need and<br>
committing the patch, and the more often issues are found *before*<br>
commit, the more frequently we can do releases.<br>
<br>
Cheers,<br>
Steve<br>
<br>
<br>
<br>
_______________________________________________<br>
Python-Dev mailing list<br>
<a href="mailto:Python-Dev@python.org" target="_blank">Python-Dev@python.org</a><br>
<a href="https://mail.python.org/mailman/listinfo/python-dev" rel="noreferrer" target="_blank">https://mail.python.org/mailman/listinfo/python-dev</a><br>
Unsubscribe: <a href="https://mail.python.org/mailman/options/python-dev/brett%40python.org" rel="noreferrer" target="_blank">https://mail.python.org/mailman/options/python-dev/brett%40python.org</a><br>
</blockquote></div>