Re: Adjusting DEP 10 "How Django is released" section.

[Carlton Gibson]

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 
> 
>
> 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 

Adjusting DEP 10 "How Django is released" section.

[Carlton Gibson]

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


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/CAJwKpyThHVDAjYEY8_kh%3DD__3yGopt-cn-uE10eQXQ2qUSqB8Q%40mail.gmail.com.