On Tue, Nov 29, 2011 at 8:10 PM, Luke Plant <l.plant...@cantab.net> wrote: > On 28/11/11 20:33, Adrian Holovaty wrote: > >> And that someone will be me. See my post here: >> http://www.holovaty.com/writing/back-to-django/ > > Great stuff! > >> I plan on starting this next week. Is there a list somewhere of what >> needs to get done? If not, I can make it, but obviously it'd be great >> if that already existed. > > 1) Release blockers: > > https://code.djangoproject.com/query?status=!closed&severity=Release+blocker&order=priority > > 2) Broken tests: > > http://ci.djangoproject.com/builds > > It looks like tests are failing on Oracle and spatialite. I guess any > failing tests need to be added to the release blockers. > > 3) We don't have a fully documented release process. It seems that only > James Bennett knows exactly what our release process is.
Partially true. James has documented the release process, although the link that I had to that document has gone stale. I can't remember if there was anything particularly sensitive on that release document -- if there was, that might explain why it wasn't in public circulation and on our wiki or in our docs. However, the document isn't especially complex -- it's mostly a list of things to make sure are up to date (like manifest files and version numbers). The bigger issue with releases is the bus factor on release keys -- we sign our releases tarballs, and we don't have a very high bus factor on the release keys. > Ideally we > would get this not only fully documented but fully automated, perhaps > even with the script checked in to trunk so that any of the core > developers can do a release - whether for alpha/beta/RC/final. Absolutely no disagreement here for the mechanical building parts -- it makes perfect sense that a 'releasable' tarball would be an output of a successful CI run. However, there are many parts of the build process that can't be automated -- signing packages, writing blog entries and so on. > There was a bunch of triage work to do with unreviewed tickets, but > Aymeric polished most of it off recently. This has always been one of the biggest tasks for a release -- clearing the decks for 1.3 took me a couple of weeks of spare time -- so Aymeric (and everyone else who volunteered) gets plenty of gold stars from me for doing this work :-) > Since we never had a list of features that we were committing to adding > for 1.4, I don't see any reason why we can't release an alpha as soon as > the release blockers are dealt with. I think we've ended up with a > fairly nice set of improvements despite the lack of explicit direction. > > https://docs.djangoproject.com/en/dev/releases/1.4/ Agreed. There will always be extra features that we can add (app refactor, anyone?) but I think we're well past the point where an alpha is called for. > Regarding the great Python 3 work that Vinay has done, I think this > should be deferred until after the 1.4 release, which will give the core > devs time to get up to speed with how things are going to work going > forward. Agreed. No need to either rush the Py3 work, or delay the 1.4 release any further. Yours, Russ Magee %-) -- You received this message because you are subscribed to the Google Groups "Django developers" group. To post to this group, send email to django-developers@googlegroups.com. To unsubscribe from this group, send email to django-developers+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/django-developers?hl=en.
