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/archive%40mail-archive.com
