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 (hopefully) wouldn’t make mistakes either. So that step can be dropped.
To expand on what Florian said, as far as I know, the ops team treats Jenkins as an insecure machine. Since it contains only open-source software, there’s nothing to protect. It runs on an isolated domain (djangoci.com <http://djangoci.com/>) to prevent a compromise from affecting djangoproject.com <http://djangoproject.com/> services. Significant steps to increase its security would have to be taken before it could be trusted to generate and sign releases. Best regards, -- Aymeric. > On 26 Nov 2016, at 11:02, Florian Apolloner <f.apollo...@gmail.com> wrote: > > 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 nice to have a > script which automates everything we have locally and then if we want to, we > can still put it into Jenkins. > > Cheers, > Florian > > On Friday, November 25, 2016 at 8:49:54 PM UTC+1, 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 has improved. > > Currently doing a release requires bumping the VERSION tuple in > django/__init__.py [0], creating tarball/wheel and checksum files, asking > someone in IRC to verify the checks look fine, and upload files to various > locations [1]. My idea would be to use setuptools_scm [2] (that choice > because this is the only tool I know about) to eliminate the need to bump/set > a VERSION tuple and instead fetch the version information based on git tags. > Something like (based on what I found in djanog-hosts [3]): > > __version__ = pkg_resources.get_distribution('django').version > > One issue I'm not sure how to deal with is how to provides > backwards-compatibility for django.VERSION, the tuple format that looks > something like: > > VERSION = (1, 11, 0, 'alpha', 0) > > I think removing or deprecating it would be quite disruptive for the > community as I've seen lots of third-party apps that do checks like "if > django.VERSION < (1, 9): ...", for example. I suspect it's possible to parse > the version string to create something similar, but I wondered if anyone has > experience with that. > > Finally, uploading to PyPI and djangoproject.com <http://djangoproject.com/> > (release and checksum files) could be done automatically by Jenkins or > something similar. > > Thanks for your comments, concerns, and suggestions. > > [0] > https://github.com/django/django/blob/6252fd6314f66d2d303cc47c791ffefd27169b42/django/__init__.py#L5 > > <https://github.com/django/django/blob/6252fd6314f66d2d303cc47c791ffefd27169b42/django/__init__.py#L5> > [1] > https://docs.djangoproject.com/en/dev/internals/howto-release-django/#actually-rolling-the-release > > <https://docs.djangoproject.com/en/dev/internals/howto-release-django/#actually-rolling-the-release> > [2] https://github.com/pypa/setuptools_scm > <https://github.com/pypa/setuptools_scm> > [3] > https://github.com/jazzband/django-hosts/blob/0eae77b31927ddb0267943d6f9bcfc22f14706f2/django_hosts/__init__.py#L11 > > <https://github.com/jazzband/django-hosts/blob/0eae77b31927ddb0267943d6f9bcfc22f14706f2/django_hosts/__init__.py#L11> > > -- > You received this message because you are subscribed to the Google Groups > "Django developers (Contributions to Django itself)" group. > To unsubscribe from this group and stop receiving emails from it, send an > email to django-developers+unsubscr...@googlegroups.com > <mailto:django-developers+unsubscr...@googlegroups.com>. > To post to this group, send email to django-developers@googlegroups.com > <mailto:django-developers@googlegroups.com>. > Visit this group at https://groups.google.com/group/django-developers > <https://groups.google.com/group/django-developers>. > To view this discussion on the web visit > https://groups.google.com/d/msgid/django-developers/3a3a59e7-b4e4-4bc9-8538-67d040459840%40googlegroups.com > > <https://groups.google.com/d/msgid/django-developers/3a3a59e7-b4e4-4bc9-8538-67d040459840%40googlegroups.com?utm_medium=email&utm_source=footer>. > For more options, visit https://groups.google.com/d/optout > <https://groups.google.com/d/optout>. -- You received this message because you are subscribed to the Google Groups "Django developers (Contributions to Django itself)" group. To unsubscribe from this group and stop receiving emails from it, send an email to django-developers+unsubscr...@googlegroups.com. To post to this group, send email to django-developers@googlegroups.com. Visit this group at https://groups.google.com/group/django-developers. To view this discussion on the web visit https://groups.google.com/d/msgid/django-developers/5BEC099B-06F3-47CA-A6B5-84B18248E9C4%40polytechnique.org. For more options, visit https://groups.google.com/d/optout.
