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.do...@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....@python.org on behalf of > srku...@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@python.org > https://mail.python.org/mailman/listinfo/python-dev > Unsubscribe: > https://mail.python.org/mailman/options/python-dev/brett%40python.org >
_______________________________________________ Python-Dev mailing list Python-Dev@python.org https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
