Fellow Report - November 26, 2016

Triaged --- https://code.djangoproject.com/ticket/27520 - sqlmigrate generates a duplicate DROP INDEX statement (duplicate) https://code.djangoproject.com/ticket/27483 - Add a login_required decorator for AJAX requests (wontfix) https://code.djangoproject.com/ticket/27498 - Filtering

Re: automating Django releases

Hi Tim, On 11/25/2016 11:49 AM, Tim Graham wrote: > After doing releases about once a month for a while, I'm thinking it > would be nice if releasing Django could be a bit more automated. As far > as I know, the process hasn't changed too much in 10 years, while the > state of Python packaging

Re: automating Django releases

Appreciate the security concerns of the jenkins boxes, but Jenkins is the obvious choice as a task runner. My first thought would be to bring up a special slave that was particularly hardened and walled off from the regular PR runners. I'm unsure how far access to the slave from the master

Re: automating Django releases

I agree that most of the workflow could be scripted. The manual verification step for checksums exists because there was an error in checksums once in the distant past and we took some flak for that. Since you’re making releases regularly, you’re much less likely to make a mistake. A script

Re: automating Django releases

Hi, +1 to automating as much as possible; one thing though: Personally I do not like uploading via Jenkins as a security issue there might compromise our PyPi account. This is especially important if a build slave where able to do something to the master… So I think as first step it would be

Re: automating Django releases

I'm pretty confident we can just automate the process you currently do. On 26 November 2016 at 05:40, Josh Smeaton wrote: > I think automating as much of the release process is a fantastic idea. > Regarding bumping the release numbers, have you seen the bumpversion >