Almost scared to say it but, the discussion on the TB renaming and election eligibility changes highlights the inappropriateness of the How Django is released section of DEP 10.
It currently reads:
No later than one week after the release of each Feature Release of Django, the Technical Board SHALL determine and publish a schedule for the following Feature Release. Bugfix Releases for each supported Feature Release SHALL be scheduled to occur on a monthly basis.
Releases of Django will occur as follows:
- When the scheduled date of a Feature Release, of an alpha/beta/candidate package for a Feature Release, or of a Bugfix Release is less than one week away, the Technical Board MAY, by vote, request that the Releasers not issue the release on the scheduled date. In the event that the Technical Board does make such a request, the Releasers MUST NOT issue the release until such time as they receive an update from the Technical Board granting permission for the release. If the Technical Board requests that a release not be issued, they SHALL provide public notice, on the django-developers mailing list or the Django Forum, of their reasoning, and SHALL provide timely updates regarding the status of the release.
- At any time, the Django Security Team MAY ask a Releaser to issue one or more Security Releases of Django, regardless of prior schedule, in order to handle a security issue under Django's security process. When the Django Security Team makes such a request, the Releaser MUST issue the requested release(s) at or as close as is practicable to the time of release requested by the Django Security Team. The Technical Board MUST NOT attempt to prevent such release(s) from occurring; if the Technical Board feels such release(s) are or were inappropriate, the Technical Board may take action after the release(s).
Django has a fixed eight monthly release schedule — Apr - Dec - Aug, and back to Apr over a 24month period. This is entirely mechanical. It's one of Django's great strengths. Any change to that would be significant and require a DEP itself; nobody took DEP10 to be trying to change that, we'd agree I presume.
The opening paragraph should mention the eight month cycle and say a Releaser SHALL determine and publish a schedule for the following Feature Release. The reality is this falls to one of the Fellows, who by convention alternate the release manager role for each major version. The TB/SC SHOULD (and DO, and HAVE) acted to review the proposed schedule to suggest tweaks, for example Adam noticed a suggested Apr 1 final release which we avoided.
Then, requiring a vote to allow the release in point 1 should be removed. The release goes ahead unless there's a reason not to. The TB/SC of course should have that oversight, but the release should be automatic unless there's a proposal to stop it. There's no benefit to having a release potentially delayed because a vote wasn't held. There's no benefit to organising a vote that merely rubber stamps an automatic, long-standing process. (It's no surprise this vote hasn't been happening, as it doesn't map to the actual workflow. The conflict is an issue with the DEP, not the workflow.)
Point 2 is fine. We've done such once during my time as Fellow. I've also though had to make one release due to a packaging error, so we should probably have something along the lines of, "In exceptional circumstances...", which I would have had "hot" security releases under if it wasn't there already.
To James' wider point about supposedly discarding DEP 10, I don't see that at all. Rather, the most of it is great. It was written in abstract though, so it's to be expected that we would revise given experience of how it applies in practice.
I will create the draft DEP to fulfil the formalities here, and ask for a TB vote next week.