Hi All. I've drafted up a DEP for this adjustment here:
https://github.com/django/deps/pull/76 Please have a look if you're interested. I've initially asked for review from the Technical Board and from James, as the author of DEP 10, but any other input appreciated. To simplify the remaining discussions, I'd like to move this forward to a Technical Board vote sooner rather than later. Thanks. Kind Regards, Carlton On Thursday, 27 October 2022 at 08:56:25 UTC+2 Carlton Gibson wrote: > Hi all, > > 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: > > How Django is released > <https://github.com/django/deps/tree/main/accepted#id20> > > 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: > > 1. 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. > 2. 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). > > > Src: > https://github.com/django/deps/blob/main/accepted/0010-new-governance.rst#how-django-is-released > > 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. > > Kind Regards, > > Carlton > > > > > > -- 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 view this discussion on the web visit https://groups.google.com/d/msgid/django-developers/6251f9c4-0ffd-4236-81a0-7ab7d282ececn%40googlegroups.com.
