<html><head><meta http-equiv="content-type" content="text/html; charset=utf-8"></head><body dir="auto"><div><span style="background-color: rgba(255, 255, 255, 0);">The bots Mozilla runs around both Rust and Servo should make a lot of this much lower overhead if they can be repurposed (as I believe several other communities have already done).</span></div><div id="AppleMailSignature"><br></div><div id="AppleMailSignature">Homu, the build manager tool, runs CI (including buildbots, Travis, etc.), is integrated with GitHub PRs so maintainers can trigger it with a comment there, and can also roll up a bunch of changes into one (handy to pull together e.g. a bunch of small documentation changes like typo fixes): <a href="https://github.com/barosl/homu">https://github.com/barosl/homu</a> <span style="background-color: rgba(255, 255, 255, 0);">That seems to keep the pain level of having an always-building-and-passing-tests nightly version much lower.</span></div><div id="AppleMailSignature"><br></div><div id="AppleMailSignature"><span style="background-color: rgba(255, 255, 255, 0);">Aside: I don't want to flood these discussions with "yay Rust!" stuff, so this will probably be my last such response unless something else really jumps out. ;-) Thanks for the work you're all doing here.</span><br><br>Regards,<div>Chris Krycho</div></div><div><br>On Jul 3, 2016, at 7:34 PM, Nick Coghlan <<a href="mailto:ncoghlan@gmail.com">ncoghlan@gmail.com</a>> wrote:<br><br></div><blockquote type="cite"><div><span>On 4 July 2016 at 00:39, Guido van Rossum <<a href="mailto:guido@python.org">guido@python.org</a>> wrote:</span><br><blockquote type="cite"><span>Another thought recently occurred to me. Do releases really have to be</span><br></blockquote><blockquote type="cite"><span>such big productions? A recent ACM article by Tom Limoncelli[1]</span><br></blockquote><blockquote type="cite"><span>reminded me that we're doing releases the old-fashioned way --</span><br></blockquote><blockquote type="cite"><span>infrequently, and with lots of manual labor. Maybe we could</span><br></blockquote><blockquote type="cite"><span>(eventually) try to strive for a lighter-weight, more automated</span><br></blockquote><blockquote type="cite"><span>release process? It would be less work, and it would reduce stress for</span><br></blockquote><blockquote type="cite"><span>authors of stdlib modules and packages -- there's always the next</span><br></blockquote><blockquote type="cite"><span>release. I would think this wouldn't obviate the need for carefully</span><br></blockquote><blockquote type="cite"><span>planned and timed "big deal" feature releases, but it could make the</span><br></blockquote><blockquote type="cite"><span>bug fix releases *less* of a deal, for everyone.</span><br></blockquote><span></span><br><span>Yes, getting the maintenance releases to the point of being largely</span><br><span>automated would be beneficial. However, I don't think the problem is</span><br><span>lack of desire for that outcome, it's that maintaining the release</span><br><span>toolchain pretty much becomes a job at that point, as you really want</span><br><span>to be producing nightly builds (since the creation of those nightlies</span><br><span>in effect becomes the regression test suite for the release</span><br><span>toolchain), and you also need to more strictly guard against even</span><br><span>temporary regressions in the maintenance branches.</span><br><span></span><br><span>There are some variants we could pursue around that model (e.g.</span><br><span>automating Python-only updates without automating updates that require</span><br><span>rebuilding the core interpreter binaries for Windows and Mac OS X),</span><br><span>but none of it is the kind of thing likely to make anyone say "I want</span><br><span>to work on improving this in my free time". Even for commercial</span><br><span>redistributors, it isn't easy for us to make the business case for</span><br><span>assigning someone to work on it, since we're generally working from</span><br><span>the source trees rather than the upstream binary releases.</span><br><span></span><br><span>I do think it's worth putting this into our bucket of "ongoing</span><br><span>activities we could potentially propose to the PSF for funding",</span><br><span>though. I know Ewa (Jodlowska, the PSF's Director of Operations) is</span><br><span>interested in better supporting the Python development community</span><br><span>directly (hence <a href="https://donate.pypi.io/">https://donate.pypi.io/</a> ) in addition to the more</span><br><span>indirect community building efforts like PyCon US and the grants</span><br><span>program, so I've been trying to build up a mental list of CPython</span><br><span>development pain points where funded activities could potentially</span><br><span>improve the contributor experience for volunteers. So far I have:</span><br><span></span><br><span>- issue triage (including better acknowledging folks that help out</span><br><span>with triage efforts)</span><br><span>- patch review (currently "wait and see" pending the impact of the</span><br><span>GitHub migration)</span><br><span>- nightly pre-release builds (for ease of contribution without first</span><br><span>becoming a de facto C developer and to help make life easier for</span><br><span>release managers)</span><br><span></span><br><span>That last one is a new addition to my list based on this thread, and I</span><br><span>think it's particularly interesting in that it would involve a much</span><br><span>smaller set of target users than the first two (with the primary</span><br><span>stakeholders being the release managers and the folks preparing the</span><br><span>binary installers), but also a far more concrete set of deliverables</span><br><span>(i.e. nightly binary builds being available for active development and</span><br><span>maintenance branches for at least Windows and Mac OS X, and</span><br><span>potentially for the manylinux1 baseline API defined in PEP 513)</span><br><span></span><br><span>Cheers,</span><br><span>Nick.</span><br><span></span><br><span>-- </span><br><span>Nick Coghlan | <a href="mailto:ncoghlan@gmail.com">ncoghlan@gmail.com</a> | Brisbane, Australia</span><br><span>_______________________________________________</span><br><span>Python-Dev mailing list</span><br><span><a href="mailto:Python-Dev@python.org">Python-Dev@python.org</a></span><br><span><a href="https://mail.python.org/mailman/listinfo/python-dev">https://mail.python.org/mailman/listinfo/python-dev</a></span><br><span>Unsubscribe: <a href="https://mail.python.org/mailman/options/python-dev/chris%40chriskrycho.com">https://mail.python.org/mailman/options/python-dev/chris%40chriskrycho.com</a></span><br></div></blockquote></body></html>