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
RetroSearch is an open source project built by @garambo | Open a GitHub Issue
Search and Browse the WWW like it's 1997 | Search results from DuckDuckGo
HTML:
3.2
| Encoding:
UTF-8
| Version:
0.7.4