Re: #21978 include production-ready web server

[Florian Apolloner]

Hi Pete,

this does look interesting. And I agree that this is something that would 
be nice to have in core in one form or another. That said I think we have 
to do it iteratively (ie in smaller parts) and evaluate along the way.

Since you asked for feedback, I'll tell you what I'd do differently (and 
this is also a sign that production environment vary widely).

 * As soon as health checks check something aside from simply returning a 
200 status code I'd want to be able to limit access to them
 * I like my dev env to be as close as possible to production so I usually 
also use whitenoise in dev. I had to many times where dev worked and 
whitenoise in prod failed then :D
 * I do hate `DJANGO_ENV` but I guess there is no way around it. Currently 
my projects often piggy-back on DEBUG but that can be rather hard from time 
to time
 * I prefer settings in settings files (ini/yaml/toml) as opposed to env 
variables that leak down the whole process-tree. django-environ does 
support this; that said there are other options like dynaconf which also 
support hashicorp vault which is a massive plus imo. Just being able to 
utilize vault for free from every django application out there would be 
stellar.

Another thing about settings, and this is something I really like in 
spring-boot is their relaxed binding for configuration variables. You can 
look at 
https://github.com/spring-projects/spring-boot/wiki/Relaxed-Binding-2.0 for 
an example. They describe there how hierarchical variables are handled and 
translated between yaml and env variables. Of course this binding is not 
exactly bidirectional always (I think) but it allows for a few nice things. 
First off you can start with a config file in yaml (one might dislike yaml 
but I find it easier to read than say a .env file with 100 settings):

```
db:
  host: myhost
  port: 1234

caches:
  default:
 type: memory
  second:
type: redis
```

which would translate to the following env variables:
```
DB_HOST: myhost
DB_PORT: 1234
CACHES_DEFAULT_TYPE: memory
CACHES_SECOND_TYPE: redis
``` 

This is imo really a powerful concept and allows for so much nicer and 
easier definitions.

Cheers,
Florian

On Friday, October 21, 2022 at 9:56:50 PM UTC+2 pe...@lincolnloop.com wrote:

> I put together a first stab at this at 
> https://github.com/lincolnloop/django-production. Feedback is appreciated!
>
> On Tue, Aug 23, 2022 at 1:34 PM pe...@lincolnloop.com <
> pe...@lincolnloop.com> wrote:
>
>> I hadn't seen django-simple-deploy. At first glance, it looks 
>> interesting, but more platform-specific than what I was thinking.
>>
>> I'll play around with creating a third-party app that encapsulates some 
>> of these thoughts and see where I end up.
>>
>> Thanks for your time and feedback!
>>
>> On Tuesday, August 23, 2022 at 1:17:12 PM UTC-6 carlton...@gmail.com 
>> wrote:
>>
>>> Hey Pete. 
>>>
>>> Yes, there can be a lot of steps... (and trouble is every one has a 
>>> different opinion once you get to specifics :) 
>>>
>>> django-webserver looks good — in a similar ballpark to what I had in 
>>> mind, yes, but I'd probably not want to bundle the options for each server 
>>> myself, as that seems a lot to maintain over time... (Better to outsource 
>>> to the individual projects no?)  
>>>
>>> Have you seen what Eric Matthes is doing with django-simple-deploy? 
>>>
>>> https://github.com/ehmatthes/django-simple-deploy
>>>
>>> I really like the idea: in an opinionated way, it applies the project 
>>> changes you need to deploy (and it's plugable so folks could provide a 
>>> *template* for their own flavour of deployment if they wanted, which is 
>>> kind of important given the number of options in the landscape, even if you 
>>> only to *ship* a beginner option.) 
>>>
>>> Tim Allen also recently raised improving the Django project template, 
>>> which I think is related here. (That's on my list too: async this QTR, then 
>>> hoping to take on Adam's proposal to modernise the Request object for the 
>>> end of year, then 🤞 swinging back here for "OK, what does it look like, 
>>> what can we do?" after that: there's a bunch of related tickets around 
>>> #21978 that it would be very sweet if we could clear up...) 
>>>
>>> I think all these thoughts are really pursuable outside of core in the 
>>> very short run, even if the goal is to merge them — it's much easier to 
>>> experiment that way, and then say, "This worked". 
>>>
>>> Anyhow, other than a "I've been thinking along these lines", and a 
>>> generally positive emote, I don't have too much more concrete at this 
>>> stage. 
>>> 👍
>>> C.
>>>
>>> On Tue, 23 Aug 2022 at 19:00, Peter Baumgartner  
>>> wrote:
>>>
 Thanks for the additional background Carlton! I like the idea of
 having some sort of protocol that folks can follow to make
 ready-to-use Django server packages (django-webserver [1] is in the
 same vein), but I'd strive for more. pip install + INSTALLED_APPS is
 great, but getting to

Re: Creating internal/admin pages without Models

[Vasanth Mohan]

Hi Carlton,

While django-admin-views 
indeed gives us the option to add custom views, it still is locked to the
App/Model based organisation which reflects the DB. Moreover, it still
necessitates that I build the page by hand.

I'm interested to know if it would be possible to reuse the admin widgets
like ListView Table with its filters, search etc on a custom view.

Thanks,
Vasanth MOHAN


On Tue, 25 Oct 2022 at 21:40, Carlton Gibson 
wrote:

> Check out Django-admin-views
>
> https://github.com/frankwiles/django-admin-views
>
> I think it needs a bit of an update for recent versions of Django (but I
> suspect those are minor) and o tho knit does what you’re after (or close)
>
> On Tuesday, 25 October 2022, Vasanth Mohan  wrote:
>
>> Hi Igor,
>>
>> Most of my cases are for internal tools and grouping together unrelated
>> tables as you just summarised. Some examples are,
>>
>> - Writing text that can need to send out to clients by triggering a
>> predefined email templates
>> - Creating internal forms that should be saved to multiple tables or
>> throw an error
>> - Custom templates for showing unrelated & unrelated data
>>
>> While these can be done normally with templates, the key difference is
>> these are internal pages and do not need to be super stylised. Performance
>> is far more important than the UI. A minimal stylisation would be good
>> enough is most cases.
>>
>> Being able to leverage admin widgets would improve task turnaround time
>> and reduce frontend work to only client-facing logic.
>>
>>
>> Vasanth MOHAN
>>
>>
>> On Tue, 25 Oct 2022 at 14:10, Igor Margitich  wrote:
>>
>>> Hi Vasanth,
>>>
>>> Can you ptovide an example when do you need generic admin view? I have
>>> case where I need gather some information from different not directly
>>> related tables. I have used
>>> https://pypi.org/project/django-nonrelated-inlines/. Can't say it is
>>> exactly what I need but seems it does the job.
>>> Also sometimes I need action's intermediate page which is more then just
>>> simple template. This is the case where would be nice to have CBV. Watch
>>> this presentation to get some ideas about CBV actions
>>> https://youtu.be/HJfPkbzcCJQ?t=1817.
>>>
>>> Best regards,
>>> Ihor
>>>
>>> вт, 25 окт. 2022 г. в 11:22, Vasanth Mohan :
>>>
 Hello,

 I'd like to gauge the general opinion of more experienced devs before
 starting on a project.

 I personally love the sheer flexibility that the django admin provides
 me to get started on the DB and manage the backend. I can add actions,
 filters and charts with just a few third-party apps. On top of that,
 permissions to control user access to everything.

 However, I find myself having to build a separate set of templates and
 view for internal use often as the admin is tightly tied to the DB. I find
 myself not being able to expose the admin as it requires too much
 customisation to be useful to tech & non-tech teams at the same time.
 Moreover, DB structure is not as intuitive to non-tech users.

 So I'd like to build a generic admin view that is not tied to the DB
 but can still leverage the widgets (tables, inputs, messages etc.) that
 Django offers. A set of tools to design custom pages like django-etc and
 design easy-to-customise top/sidebars

 My question to the reader is quite simple, is this something feasible ?
 Are all widgets tightly coupled and expect models to function ? Anything
 you believe that might trip me up?

 Thanks,
 Vaz

 --
 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/d6146414-c423-4f2a-b482-5eccb971f16cn%40googlegroups.com
 
 .

>>> --
>>> You received this message because you are subscribed to a topic in the
>>> Google Groups "Django developers (Contributions to Django itself)" group.
>>> To unsubscribe from this topic, visit
>>> https://groups.google.com/d/topic/django-developers/yFJz4GPTJPo/unsubscribe
>>> .
>>> To unsubscribe from this group and all its topics, 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/CAHi_fyv7QrWwpNOdyv8ZvOg%2B84mzTLKvrc-iYHjee8SQ6gPd%2Bg%40mail.gmail.com
>>> 
>>> .
>>

Re: #21978 include production-ready web server

[Jure Erznožnik]

IMHO, adding YAML support would introduce a dependency that's not 
needed: why not just use Python, instead of ini/yaml/toml?


Projects could have a (.gitignore) env.py that settings.py imports and 
then sets the appropriate variables from it. You can use straight 
assignment, e.g.


   LANGUAGE_CODE = env.LANGUAGE_CODE

or a getattr for optional settings:

   LANGUAGE_CODE = getattr(env, 'LANGUAGE_CODE', 'en-gb')

No dependencies at all, not even internal python ones.

But maybe I'm just being ignorant: there must be good reasons if core 
python accepted toml. In that case, I hope to be enlightened (no sarcasm 
here).


LP,
Jure

On 26. 10. 22 09:30, Florian Apolloner wrote:

Hi Pete,

this does look interesting. And I agree that this is something that 
would be nice to have in core in one form or another. That said I 
think we have to do it iteratively (ie in smaller parts) and evaluate 
along the way.


Since you asked for feedback, I'll tell you what I'd do differently 
(and this is also a sign that production environment vary widely).


 * As soon as health checks check something aside from simply 
returning a 200 status code I'd want to be able to limit access to them
 * I like my dev env to be as close as possible to production so I 
usually also use whitenoise in dev. I had to many times where dev 
worked and whitenoise in prod failed then :D
 * I do hate `DJANGO_ENV` but I guess there is no way around it. 
Currently my projects often piggy-back on DEBUG but that can be rather 
hard from time to time
 * I prefer settings in settings files (ini/yaml/toml) as opposed to 
env variables that leak down the whole process-tree. django-environ 
does support this; that said there are other options like dynaconf 
which also support hashicorp vault which is a massive plus imo. Just 
being able to utilize vault for free from every django application out 
there would be stellar.


Another thing about settings, and this is something I really like in 
spring-boot is their relaxed binding for configuration variables. You 
can look at 
https://github.com/spring-projects/spring-boot/wiki/Relaxed-Binding-2.0 
for an example. They describe there how hierarchical variables are 
handled and translated between yaml and env variables. Of course this 
binding is not exactly bidirectional always (I think) but it allows 
for a few nice things. First off you can start with a config file in 
yaml (one might dislike yaml but I find it easier to read than say a 
.env file with 100 settings):


```
db:
  host: myhost
  port: 1234

caches:
  default:
     type: memory
  second:
    type: redis
```

which would translate to the following env variables:
```
DB_HOST: myhost
DB_PORT: 1234
CACHES_DEFAULT_TYPE: memory
CACHES_SECOND_TYPE: redis
```

This is imo really a powerful concept and allows for so much nicer and 
easier definitions.


Cheers,
Florian

On Friday, October 21, 2022 at 9:56:50 PM UTC+2 pe...@lincolnloop.com 
wrote:


I put together a first stab at this at
https://github.com/lincolnloop/django-production. Feedback is
appreciated!

On Tue, Aug 23, 2022 at 1:34 PM pe...@lincolnloop.com
 wrote:

I hadn't seen django-simple-deploy. At first glance, it looks
interesting, but more platform-specific than what I was thinking.

I'll play around with creating a third-party app that
encapsulates some of these thoughts and see where I end up.

Thanks for your time and feedback!

On Tuesday, August 23, 2022 at 1:17:12 PM UTC-6
carlton...@gmail.com wrote:

Hey Pete.

Yes, there can be a lot of steps... (and trouble is every
one has a different opinion once you get to specifics :)

django-webserver looks good — in a similar ballpark to
what I had in mind, yes, but I'd probably not want to
bundle the options for each server myself, as that seems a
lot to maintain over time... (Better to outsource to the
individual projects no?)

Have you seen what Eric Matthes is doing with
django-simple-deploy?

https://github.com/ehmatthes/django-simple-deploy

I really like the idea: in an opinionated way, it applies
the project changes you need to deploy (and it's plugable
so folks could provide a *template* for their own flavour
of deployment if they wanted, which is kind of important
given the number of options in the landscape, even if you
only to *ship* a beginner option.)

Tim Allen also recently raised improving the Django
project template, which I think is related here. (That's
on my list too: async this QTR, then hoping to take on
Adam's proposal to modernise the Request object for the
end of year, then 🤞 swinging back here for "OK, what does
it look like, what can we do?" after that: there's 

Proposal: Clarify individual members page

[Andrew Mshar]

Along the lines of discussions about redefining requirements for board 
seats (e.g. https://groups.google.com/g/django-developers/c/FbNaAq3rz6c), I 
think it would be helpful to clarify what we want from individual members 
of the DSF here:

https://www.djangoproject.com/foundation/individual-members/

As a non-member who recently made my first contribution to Django, I looked 
at that page and thought: is that enough for me to be a member? I'm not 
particularly concerned about my own membership, but rather, this made me 
realize that the lack of clarity may prevent others from joining who 
otherwise should.

Is there anywhere that we have a more clear outline of what we expect from 
members both before they join and after? If not, could we have that 
discussion here to clarify for future members?

Thanks,
Andrew

-- 
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/824f1e56-64f1-44e4-9612-dc121c5d3efcn%40googlegroups.com.

Re: Changing the role of the Technical Board

[James Bennett]

I'm going to avoid trying to get too much into point-by-point
back-and-forth argument here, and try to present the larger picture.

The Technical Board has multiple active responsibilities under DEP 10.
Let's look at some of them:

1. Canvas for feature proposals once per feature release of Django. This
also comes with a responsibility to ensure the proposals are archived in a
useful way -- we used to have wiki pages in Trac for this, but DEP 10
doesn't require any specific mechanism. This is supposed to happen within
one week after feature freeze of each feature release.

2. Set the release schedule for each feature release of Django. This is
supposed to happen within one week after the prior feature release coming
out.

3. Maintain the teams of Mergers and Releasers, including by nominating and
confirming new members of those teams when the Technical Board considers it
necessary (or when the current roster falls below the DEP 10 quorum).

4. Vote, as requested, on DEPs.

5. Vote, as requested, on any technical decision that fails to resolve
through normal public discussion.

(1) has not been happening. It's possible that (2) has been happening and
just hasn't been that formally published, but I suspect it's been the
Fellows who've been doing that one. For 3-5, things have gone... not so
great.

It took multiple attempts to get the Technical Board to vote on the first
Merger nomination (Claude), and if we're being pedantic it still wasn't
quite done correctly because his appointment as a Merger should have been
temporary and auto-expired after the first Technical Board election unless
the new Board voted to confirm him permanently.

The first time the Technical Board voted on a DEP was the proposed DEP 484
for type hints. The Technical Board's discussion and voting on it
apparently took place entirely in private and the result was communicated
publicly via Carlton copy/pasting the reply he got from them. And we lucked
out that the Board didn't accept the DEP, because it was at a time when an
election was pending and thus they had no power to accept a DEP (similar to
the Merger nomination -- once an election triggers, the Board cannot accept
DEPs and can only make temporary appointments of Mergers/Releasers).

On (5) the only explicit request I can find in this mailing list's archive
is one from Carlton to make a decision on ticket 31747. Although several
Technical Board members posted opinions in response, I'm not finding any
statements of their votes on the matter.

If grant a half point for the Merger nomination (though the Board really
ought to hold a public vote to properly permanently confirm Claude), and
maybe another half point for the fact that release schedules have been
getting set (though, I suspect, not explicitly by the Board), that gets us
to 1 out of a possible 5. This is not a great track record.

Before we propose a different setup, I think we need to figure out what
went wrong here. It already seems like some members of the Technical Board
may not have really been familiar with the responsibilities, or may not
have understood that some of the required duties were in fact required. And
it seems that several members of the Technical Board found themselves in
positions where they didn't have the time/capacity to carry out the
responsibilities, but also took no action to communicate this outside the
Technical Board.

Are these things that would be solved by yet another governance rewrite? Or
are they things that could just as easily happen again? I suspect the
latter. So I think proposals for new governance should be on hold for now
until these things are sorted out.

Also, on a personal note, I'd be a bit annoyed if DEP 10 were basically
tossed aside without being properly tried in practice.

-- 
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/CAL13Cg-Y90u7wH8v9ZoWRT_5ZEnr%3Dhpe9ga6t28tn%2BrPH_Ussg%40mail.gmail.com.

Re: Changing the role of the Technical Board

[Andrew Godwin]

I agree the Technical Board has not followed the letter of DEP 10, and I think 
the things you have highlighted are all valid failings, but I want to focus on 
- what should we do to remedy them?

Given the lack of candidates we already have, if we ditch the current Board and 
try to elect a new one that has to do all these things, it's likely we will 
fail to have a valid election, and from what I recall, there is no provision 
for that in DEP 10.

We could consider changing to a board size of three to overcome this, but that 
would increase the workload even further.  We could hope that five incredibly 
willing people are waiting in the wings, but I doubt it.

At this point, it is my view that it is our job to govern with the people we 
have, and the time and energy they can provide, and that's my intention with 
these suggested changes.

I honestly think you and I both want the Board to do the same rough role - my 
current draft "extension DEP" on top of DEP 10 is literally just "change the 
name and tweak the eligibility clauses", it's not like we're going to throw it 
out. I just want to come at this a bit more incrementally with our current set 
of people, and throw the net a bit wider so we do have more of a chance of 
finding five people with the energy to run the tasks assigned to the Board with 
the vision we initially had.

At the end of the day, my feeling is that inaction is not the right path - we 
need to enact some sort of change. I'm more than willing to hear alternative 
suggestions for what that change should be (though as outlined previously, I 
really don't think that change should be "remove the entire current Board for 
underperformance and have another election").

Andrew

On Wed, Oct 26, 2022, at 12:23 PM, James Bennett wrote:
> I'm going to avoid trying to get too much into point-by-point back-and-forth 
> argument here, and try to present the larger picture.
> 
> The Technical Board has multiple active responsibilities under DEP 10. Let's 
> look at some of them:
> 
> 1. Canvas for feature proposals once per feature release of Django. This also 
> comes with a responsibility to ensure the proposals are archived in a useful 
> way -- we used to have wiki pages in Trac for this, but DEP 10 doesn't 
> require any specific mechanism. This is supposed to happen within one week 
> after feature freeze of each feature release.
> 
> 2. Set the release schedule for each feature release of Django. This is 
> supposed to happen within one week after the prior feature release coming out.
> 
> 3. Maintain the teams of Mergers and Releasers, including by nominating and 
> confirming new members of those teams when the Technical Board considers it 
> necessary (or when the current roster falls below the DEP 10 quorum).
> 
> 4. Vote, as requested, on DEPs.
> 
> 5. Vote, as requested, on any technical decision that fails to resolve 
> through normal public discussion.
> 
> (1) has not been happening. It's possible that (2) has been happening and 
> just hasn't been that formally published, but I suspect it's been the Fellows 
> who've been doing that one. For 3-5, things have gone... not so great.
> 
> It took multiple attempts to get the Technical Board to vote on the first 
> Merger nomination (Claude), and if we're being pedantic it still wasn't quite 
> done correctly because his appointment as a Merger should have been temporary 
> and auto-expired after the first Technical Board election unless the new 
> Board voted to confirm him permanently.
> 
> The first time the Technical Board voted on a DEP was the proposed DEP 484 
> for type hints. The Technical Board's discussion and voting on it apparently 
> took place entirely in private and the result was communicated publicly via 
> Carlton copy/pasting the reply he got from them. And we lucked out that the 
> Board didn't accept the DEP, because it was at a time when an election was 
> pending and thus they had no power to accept a DEP (similar to the Merger 
> nomination -- once an election triggers, the Board cannot accept DEPs and can 
> only make temporary appointments of Mergers/Releasers).
> 
> On (5) the only explicit request I can find in this mailing list's archive is 
> one from Carlton to make a decision on ticket 31747. Although several 
> Technical Board members posted opinions in response, I'm not finding any 
> statements of their votes on the matter.
> 
> If grant a half point for the Merger nomination (though the Board really 
> ought to hold a public vote to properly permanently confirm Claude), and 
> maybe another half point for the fact that release schedules have been 
> getting set (though, I suspect, not explicitly by the Board), that gets us to 
> 1 out of a possible 5. This is not a great track record.
> 
> Before we propose a different setup, I think we need to figure out what went 
> wrong here. It already seems like some members of the Technical Board may not 
> have really been familiar with the responsibilitie

Proposal for Django Core Sprints

[Paolo Melchiorre]

Hi everyone,

Following Andrew Godwin's example, I too share with you a proposal
that I made during DjangoCon US 2022 and that I have already shared
with some of you.

Inspired by an article by Will Vincent, I wrote my proposal for Django
Core Sprints, and its genesis, in an article and would also like to
have the opinions of the Django community members interested in the
idea:
https://www.paulox.net/2022/10/26/about-my-proposal-for-the-django-core-sprints/

Ciao,
Paolo
-- 
Paolo Melchiorre

https://www.paulox.net

-- 
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/CAKFO%2Bx6FAf-M14fKx5QS1K8rru2L3mOiR1R%3Dn6FzDk%3DrnaUq3A%40mail.gmail.com.

Re: Changing the role of the Technical Board

[James Bennett]

On Wed, Oct 26, 2022 at 12:02 PM Andrew Godwin  wrote:

> At this point, it is my view that it is our job to govern with the people
> we have, and the time and energy they can provide, and that's my intention
> with these suggested changes.
>

If the problem in front of us is that the Technical Board isn't up to the
level of activity DEP 10 asks of them, and you believe no substitute group
of members exists that would be up to it either, I'm not sure I see how
your proposals are going to fix that, especially since you seem to
eventually want to create *more* responsibility for active intervention and
leadership.

>
At the end of the day, my feeling is that inaction is not the right path -
> we need to enact some sort of change. I'm more than willing to hear
> alternative suggestions for what that change should be (though as outlined
> previously, I really don't think that change should be "remove the entire
> current Board for underperformance and have another election").
>

A Technical Board election will automatically trigger at the release of
Django 4.2, which is not *that* far off. But the Technical Board could
always trigger an election any time they want to.

I personally would still like to understand how the current Technical Board
came to what seems to be such a misunderstanding of how the governance was
supposed to work. And while there have been explanations presented for why
the Technical Board didn't communicate the problems it was having, they
also come across as worrying -- we're all adults here, and we need to be
able to trust each other to speak up when there's a problem. How did we go,
apparently, multiple years with the Technical Board not carrying out their
responsibilities and also nobody saying anything about it?

Until we understand that I don't think we should be trying to change the
governance again.

And I still would like to see DEP 10 actually tried out. Maybe it involves
electing a Technical Board with much more explicit up-front communication
of expectations, since it seems a lot of the current members were unaware
of the Technical Board's actual responsibilities. Maybe it involves someone
just constantly poking them with reminders. Maybe something else. But it
feels wrong on many levels to start moving on from DEP 10 when it's
becoming increasingly clear that DEP 10 was never really *tried*.

-- 
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/CAL13Cg_%3DbczbtMP5B6avbNTLi%3DLf1SU_Z%3Dchz6j0u5L1MPMbzw%40mail.gmail.com.

Re: Changing the role of the Technical Board

[Andrew Godwin]

My intention is indeed for us to run a new Technical Board election come the 
end of 4.2, with much better and more explicit communication about what will be 
expected of the new members, and a larger candidate pool to pull from to 
hopefully make that work.

I will be posting my actual proposed DEP shortly so it's more clear exactly 
what I want to change at a written-rules level - I suspect feedback on a more 
concrete proposal will help us talk about it more clearly.

Andrew

On Wed, Oct 26, 2022, at 4:55 PM, James Bennett wrote:
> On Wed, Oct 26, 2022 at 12:02 PM Andrew Godwin  wrote:
>> At this point, it is my view that it is our job to govern with the people we 
>> have, and the time and energy they can provide, and that's my intention with 
>> these suggested changes.
> 
> If the problem in front of us is that the Technical Board isn't up to the 
> level of activity DEP 10 asks of them, and you believe no substitute group of 
> members exists that would be up to it either, I'm not sure I see how your 
> proposals are going to fix that, especially since you seem to eventually want 
> to create *more* responsibility for active intervention and leadership.
>> 
> 
>> At the end of the day, my feeling is that inaction is not the right path - 
>> we need to enact some sort of change. I'm more than willing to hear 
>> alternative suggestions for what that change should be (though as outlined 
>> previously, I really don't think that change should be "remove the entire 
>> current Board for underperformance and have another election").
> 
> A Technical Board election will automatically trigger at the release of 
> Django 4.2, which is not *that* far off. But the Technical Board could always 
> trigger an election any time they want to.
> 
> I personally would still like to understand how the current Technical Board 
> came to what seems to be such a misunderstanding of how the governance was 
> supposed to work. And while there have been explanations presented for why 
> the Technical Board didn't communicate the problems it was having, they also 
> come across as worrying -- we're all adults here, and we need to be able to 
> trust each other to speak up when there's a problem. How did we go, 
> apparently, multiple years with the Technical Board not carrying out their 
> responsibilities and also nobody saying anything about it?
> 
> Until we understand that I don't think we should be trying to change the 
> governance again.
> 
> And I still would like to see DEP 10 actually tried out. Maybe it involves 
> electing a Technical Board with much more explicit up-front communication of 
> expectations, since it seems a lot of the current members were unaware of the 
> Technical Board's actual responsibilities. Maybe it involves someone just 
> constantly poking them with reminders. Maybe something else. But it feels 
> wrong on many levels to start moving on from DEP 10 when it's becoming 
> increasingly clear that DEP 10 was never really *tried*.
> 
> 
> -- 
> 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/CAL13Cg_%3DbczbtMP5B6avbNTLi%3DLf1SU_Z%3Dchz6j0u5L1MPMbzw%40mail.gmail.com
>  
> .

-- 
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/88084dd9-a2e9-4271-9160-79bb463a8adc%40app.fastmail.com.

Re: Proposal for Django Core Sprints

[James Bennett]

Organizing sprints is a fine idea, but:

* They should be designed around the assumption of remote-first, not
"hybrid" or in-person-first, and there should be no language in the
description whatsoever about in-person participation being important. There
simply are too many factors involved in trying to get a bunch of people all
in one place at the same time, and privileging in-person participation is
something I will put up massive resistance to.
* But I also think you're going to find that getting people to make another
commitment on top of existing events is going to be difficult, and so it
would make more sense to formally attach the sprint to a major event like
one of the DjangoCons.

Meanwhile, I think it is absolutely essential to drop the "Core" naming,
and to drop the idea that there are special classes of contributors whose
presence is especially needed.

Those last points, for me, are non-negotiable. The Django project
explicitly has only the roles defined in DEP 10. There are no special
statuses or classes of contributors whose input is more important than
others, and that is *deliberate*.

I knew when writing DEP 10 that some folks were never going to like the
flatter setup, and would probably eventually try to re-introduce something
resembling the old core team. I'm not saying that is what you're trying to
do here, or that that's what anyone else is trying to do right now, but it
feels like the proposals being put out right now are heading in that
direction, and I want to make sure we stop that before it gets even the
tiniest bit of traction.


On Wed, Oct 26, 2022 at 3:01 PM Paolo Melchiorre 
wrote:

> Following Andrew Godwin's example, I too share with you a proposal
> that I made during DjangoCon US 2022 and that I have already shared
> with some of you.
>
> Inspired by an article by Will Vincent, I wrote my proposal for Django
> Core Sprints, and its genesis, in an article and would also like to
> have the opinions of the Django community members interested in the
> idea:
>
> https://www.paulox.net/2022/10/26/about-my-proposal-for-the-django-core-sprints/
>
> Ciao,
> Paolo
> --
> Paolo Melchiorre
>
> https://www.paulox.net
>
> --
>
> ---
> You received this message because you are subscribed to the Google Groups
> "DSF Members" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to dsf-members+unsubscr...@googlegroups.com.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/dsf-members/CAKFO%2Bx6FAf-M14fKx5QS1K8rru2L3mOiR1R%3Dn6FzDk%3DrnaUq3A%40mail.gmail.com
> .
>

-- 
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/CAL13Cg-TxdyiY623AkaB%3D_0pW_kHqy3wXTYe-Qh0Ar5CNgiV8Q%40mail.gmail.com.

Draft Steering Council DEP

[Andrew Godwin]

Hi all,

As a followup to my previous post about potential changes to the Technical 
Board - for which I thank you all for the feedback - I have taken the process 
to the next step and written a draft DEP:

https://github.com/django/deps/pull/75/files

(If you wish to see the DEP with styling, it can be viewed at 
https://github.com/andrewgodwin/deps/blob/steering/draft/0012-steering-council.rst)

I could just merge this into the DEPs repo as a draft given our process, but I 
would like to invite both review of the DEP styling and layout (to ensure it's 
ready to merge in that regard) as well as initial feedback on its content as 
well.

I have copied in the DSF Members mailing list as it is a governance-related 
DEP, but if we could keep all discussion on the thread in the Django Developers 
mailing list, as per DEP 0001, that would be great.

Thanks,
Andrew

-- 
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/4e6893a8-8e22-45a3-96f6-d56d69db7b43%40app.fastmail.com.

Re: Proposal for Django Core Sprints

[Andrew Godwin]

Hi Paolo,

I do like the overall idea - a few thoughts below.

My first concern for this, which somewhat echoes James, is that trying to 
organise an additional in-person event that a large number of contributors are 
expected to go to is difficult. Funding considerations are one concern - we 
would need to make sure everyone whose companies did not cover them to go had 
their trip paid for - but time away from home is also something that we should 
be considerate of, be it for family or for anything else.

That, too, brings an interesting challenge - who do you invite (and presumably 
help pay for)? We no longer have a core team, and I don't think it's worth 
singling the Technical Board out in this regard - the Fellows are an obvious 
requirement if they can make it, but past that, it's a hard metric to gauge.

I do like your point about disconnecting it from needing to give a talk, though 
- conferences and sprints are certainly Different Moods for me, and it can be 
draining to be sociable for three days and *then* have to go into sprints and 
be even more so. I don't know if there's a useful resolution to this specific 
problem.

My second concern is almost the opposite of that, ironically, which is that I 
do believe there are some things that benefit from synchronous, in-person 
communication. A single week at the most recent DjangoCon has done wonders for 
me in that regard, and while I do believe it should be a hybrid event, I also 
think it should *not* be a remote-only event. While it is a personal opinion, I 
find in-person sprinting significantly easier (due to the nature of the work as 
opposed to purely coding) and would probably find it hard to attend a 
remote-only sprint.

The final question I would raise is that of location. There are two elements 
here - where in the world do you hold it, and what the actual venue is like.

There is no single location in the world you will ever find where everyone can 
attend - even with very patient Australians who are far too willing to sit on 
planes for ages. It's likely you'd have to geolocate in either the Americas or 
in Europe, and if you additionally want to host it in a location that is safe 
for all attendees, that cuts down the number of US states and European 
countries even more.

And then, the venue. In the modern world, I ideally want an *outdoors* sprint 
venue, so that we're not all stuck inside a room hoping the masks work well 
enough. That places limitations on climate and season and also availability of 
power - so many that it starts to look like an impossible task to satisfy this 
along with all the above.

I don't write this as a means of discouragement - I think there's a lot to be 
said for your idea, and even though I've outlined a lot of potential flaws, I 
think a flawed event in this fashion would be better than nothing happening at 
all! I just want to highlight all the talking points we're going to need to 
really think about and have answers to if we take this forward.

(I didn't even discuss how we might fund this, which is also a conversation to 
have, but waving our hands in the air and going "sponsorship" is enough for me 
to start with)

Andrew

On Wed, Oct 26, 2022, at 4:01 PM, Paolo Melchiorre wrote:
> Hi everyone,
> 
> Following Andrew Godwin's example, I too share with you a proposal
> that I made during DjangoCon US 2022 and that I have already shared
> with some of you.
> 
> Inspired by an article by Will Vincent, I wrote my proposal for Django
> Core Sprints, and its genesis, in an article and would also like to
> have the opinions of the Django community members interested in the
> idea:
> https://www.paulox.net/2022/10/26/about-my-proposal-for-the-django-core-sprints/
> 
> Ciao,
> Paolo
> -- 
> Paolo Melchiorre
> 
> https://www.paulox.net
> 
> -- 
> 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/CAKFO%2Bx6FAf-M14fKx5QS1K8rru2L3mOiR1R%3Dn6FzDk%3DrnaUq3A%40mail.gmail.com.
> 

-- 
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/ebd86080-6735-45f7-8dd7-3ddc23c4a44d%40app.fastmail.com.

Re: Proposal for Django Core Sprints

[Paolo Melchiorre]

Hi James,

First of all, thank you for your feedback.

On Thu, Oct 27, 2022 at 1:10 AM James Bennett  wrote:
> * They should be designed around the assumption of remote-first, not "hybrid" 
> or in-person-first, ...

My proposal is that of hybrid sprints for the reasons I have listed in
my article, remote-first or remote-only sprints are totally another
proposal that maybe someone will do.

> * ... it would make more sense to formally attach the sprint to a major event 
> like one of the DjangoCons.

There are already sprints at the end of the various DjangoCon, I am
trying to propose something in addition to them.

> Meanwhile, I think it is absolutely essential to drop the "Core" naming ...

The word "core" refers to the fact that the sprints I propose are
exclusively dedicated to the Django code, unlike what happens now in
the sprints at the end of DjangoCon where people sprint on different
things.

To avoid further misunderstandings, I reiterate that the sprints I
propose are in some way similar to what already happens in other
communities, for example CPython [1] and HPy [2].

Grazie,
Paolo

[1] 
https://discuss.python.org/t/rsvp-2022-core-dev-sprint-oct-3-7-sunnyvale-ca-usa/18420
[2] https://hpyproject.org/blog/posts/2022/07/dusseldorf-sprint-2022/

> On Wed, Oct 26, 2022 at 3:01 PM Paolo Melchiorre  wrote:
>> Following Andrew Godwin's example, I too share with you a proposal
>> that I made during DjangoCon US 2022 and that I have already shared
>> with some of you.
>> Inspired by an article by Will Vincent, I wrote my proposal for Django
>> Core Sprints, and its genesis, in an article and would also like to
>> have the opinions of the Django community members interested in the
>> idea:
>> https://www.paulox.net/2022/10/26/about-my-proposal-for-the-django-core-sprints/
-- 
Paolo Melchiorre

https://www.paulox.net

-- 
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/CAKFO%2Bx4Oxxtdaf_LjERnS_z2d_awbVe5uWS3fam_EJYWT9%3DiKw%40mail.gmail.com.

Re: Proposal for Django Core Sprints

[Paolo Melchiorre]

Hi Andrew,

Thanks also to you for your very detailed answer.

On Thu, Oct 27, 2022 at 1:54 AM Andrew Godwin  wrote:

> ... trying to organise an additional in-person event that a large number of 
> contributors are expected to go to is difficult

I am aware that this proposal of mine to the DSF board is not easy,
but I think it could have positive effects as I have seen it happen in
the past and as it still happens today in other communities.

> ... who do you invite (and presumably help pay for)? We no longer have a core 
> team ...

I understand that the term "core" has triggered some old discussion
that I am not aware of, but in my proposal it refers to the scope of
the code to work on.

> ...it's a hard metric to gauge.

This is something that we could decide together.

> ... while I do believe it should be a hybrid event, I also think it should 
> not be a remote-only event.

On this point you seem to agree with my proposal

> The final question I would raise is that of location ...

I tried to give general indications on the location in my proposal so
that I could then decide a place based on the actual participants of a
given sprint, without imposing a predefined location or nation.

> I didn't even discuss how we might fund this...

Surely here too I left generic indications, because it seemed to me
more than once to understand that the DSF board would not have too
many problems in receiving new funds as long as they were destined for
a specific objective.

For example, imagine a sprint working on only one of the proposals you
listed in your last talk, it could be a point that many may have an
interest in financing directly.

Grazie,
Paolo

> On Wed, Oct 26, 2022, at 4:01 PM, Paolo Melchiorre wrote:
> Hi everyone,
> Following Andrew Godwin's example, I too share with you a proposal
> that I made during DjangoCon US 2022 and that I have already shared
> with some of you.
> Inspired by an article by Will Vincent, I wrote my proposal for Django
> Core Sprints, and its genesis, in an article and would also like to
> have the opinions of the Django community members interested in the
> idea:
> https://www.paulox.net/2022/10/26/about-my-proposal-for-the-django-core-sprints/

-- 
Paolo Melchiorre

https://www.paulox.net

-- 
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/CAKFO%2Bx7gQFCz0dg%2BL73tHyYw9wDs_v2GXH0%3D6vAxu-VQSeKWNQ%40mail.gmail.com.

Re: #21978 include production-ready web server

[Florian Apolloner]

Hi Jure,

My point was mostly about hieracrhy, not the exact format. That said on a 
technical level it is true that the same can achieved via python -- after 
all this is what settings.py is currently. But the hard truth is that many 
people prefer a established configuration file format (for some definition 
of established). Having executable files as config files can also be 
dangerous. Assume a software that reads `env.py` from `[CWD, ~/.config/app, 
/etc/app]`. Now if someone manages to convince you to run the software in a 
directory that they preconfigured with an `env.py` you will execute the 
code they want you to execute. This is part of the reason why stuff like 
`direnv` and others explicitly require you to allow a directory before 
setting env variables from `.envrc` for you (the most common offender 
obviously being someone cloning a git repo and in the case of direnv simply 
stepping into the directory executes code).

How many of the standard python tooling ala pip, flake8, black, pytest, 
tox, isort allow you to have a python file as config file? At some point 
not supporting one of the more common config file format (.ini,.yaml,.toml) 
feels like swimming against the current without any real benefit. So yes, a 
python file would suffice but I guess that battle is lost already.

Cheers,
Florian


On Wednesday, October 26, 2022 at 10:26:55 AM UTC+2 jure.er...@gmail.com 
wrote:

> IMHO, adding YAML support would introduce a dependency that's not needed: 
> why not just use Python, instead of ini/yaml/toml?
>
> Projects could have a (.gitignore) env.py that settings.py imports and 
> then sets the appropriate variables from it. You can use straight 
> assignment, e.g. 
>
> LANGUAGE_CODE = env.LANGUAGE_CODE
>
> or a getattr for optional settings:
>
> LANGUAGE_CODE = getattr(env, 'LANGUAGE_CODE', 'en-gb')
>
> No dependencies at all, not even internal python ones.
>
> But maybe I'm just being ignorant: there must be good reasons if core 
> python accepted toml. In that case, I hope to be enlightened (no sarcasm 
> here).
>
> LP,
> Jure
>
> On 26. 10. 22 09:30, Florian Apolloner wrote:
>
> Hi Pete,
>
> this does look interesting. And I agree that this is something that would 
> be nice to have in core in one form or another. That said I think we have 
> to do it iteratively (ie in smaller parts) and evaluate along the way.
>
> Since you asked for feedback, I'll tell you what I'd do differently (and 
> this is also a sign that production environment vary widely).
>
>  * As soon as health checks check something aside from simply returning a 
> 200 status code I'd want to be able to limit access to them
>  * I like my dev env to be as close as possible to production so I usually 
> also use whitenoise in dev. I had to many times where dev worked and 
> whitenoise in prod failed then :D
>  * I do hate `DJANGO_ENV` but I guess there is no way around it. Currently 
> my projects often piggy-back on DEBUG but that can be rather hard from time 
> to time
>  * I prefer settings in settings files (ini/yaml/toml) as opposed to env 
> variables that leak down the whole process-tree. django-environ does 
> support this; that said there are other options like dynaconf which also 
> support hashicorp vault which is a massive plus imo. Just being able to 
> utilize vault for free from every django application out there would be 
> stellar.
>
> Another thing about settings, and this is something I really like in 
> spring-boot is their relaxed binding for configuration variables. You can 
> look at 
> https://github.com/spring-projects/spring-boot/wiki/Relaxed-Binding-2.0 
> for an example. They describe there how hierarchical variables are handled 
> and translated between yaml and env variables. Of course this binding is 
> not exactly bidirectional always (I think) but it allows for a few nice 
> things. First off you can start with a config file in yaml (one might 
> dislike yaml but I find it easier to read than say a .env file with 100 
> settings):
>
> ```
> db:
>   host: myhost
>   port: 1234
>
> caches:
>   default:
>  type: memory
>   second:
> type: redis
> ```
>
> which would translate to the following env variables:
> ```
> DB_HOST: myhost
> DB_PORT: 1234
> CACHES_DEFAULT_TYPE: memory
> CACHES_SECOND_TYPE: redis
> ``` 
>
> This is imo really a powerful concept and allows for so much nicer and 
> easier definitions.
>
> Cheers,
> Florian
>
> On Friday, October 21, 2022 at 9:56:50 PM UTC+2 pe...@lincolnloop.com 
> wrote:
>
>> I put together a first stab at this at 
>> https://github.com/lincolnloop/django-production. Feedback is 
>> appreciated!
>>
>> On Tue, Aug 23, 2022 at 1:34 PM pe...@lincolnloop.com <
>> pe...@lincolnloop.com> wrote:
>>
>>> I hadn't seen django-simple-deploy. At first glance, it looks 
>>> interesting, but more platform-specific than what I was thinking.
>>>
>>> I'll play around with creating a third-party app that encapsulates some 
>>> of these thoughts and see where I e

Re: Proposal for Django Core Sprints

['st...@jigsawtech.co.uk' via Django developers (Contributions to Django itself)]

Hybrid sound the best way, with remote first as otherwise you are excluding 
people who would need air travel that's not covered by someone else and can 
be very expensive how and are thus increasing a carbon footprint for 
something that really doesn't need it

On Thursday, 27 October 2022 at 01:49:53 UTC+1 pa...@melchiorre.org wrote:

> Hi Andrew,
>
> Thanks also to you for your very detailed answer.
>
> On Thu, Oct 27, 2022 at 1:54 AM Andrew Godwin  wrote:
>
> > ... trying to organise an additional in-person event that a large number 
> of contributors are expected to go to is difficult
>
> I am aware that this proposal of mine to the DSF board is not easy,
> but I think it could have positive effects as I have seen it happen in
> the past and as it still happens today in other communities.
>
> > ... who do you invite (and presumably help pay for)? We no longer have a 
> core team ...
>
> I understand that the term "core" has triggered some old discussion
> that I am not aware of, but in my proposal it refers to the scope of
> the code to work on.
>
> > ...it's a hard metric to gauge.
>
> This is something that we could decide together.
>
> > ... while I do believe it should be a hybrid event, I also think it 
> should not be a remote-only event.
>
> On this point you seem to agree with my proposal
>
> > The final question I would raise is that of location ...
>
> I tried to give general indications on the location in my proposal so
> that I could then decide a place based on the actual participants of a
> given sprint, without imposing a predefined location or nation.
>
> > I didn't even discuss how we might fund this...
>
> Surely here too I left generic indications, because it seemed to me
> more than once to understand that the DSF board would not have too
> many problems in receiving new funds as long as they were destined for
> a specific objective.
>
> For example, imagine a sprint working on only one of the proposals you
> listed in your last talk, it could be a point that many may have an
> interest in financing directly.
>
> Grazie,
> Paolo
>
> > On Wed, Oct 26, 2022, at 4:01 PM, Paolo Melchiorre wrote:
> > Hi everyone,
> > Following Andrew Godwin's example, I too share with you a proposal
> > that I made during DjangoCon US 2022 and that I have already shared
> > with some of you.
> > Inspired by an article by Will Vincent, I wrote my proposal for Django
> > Core Sprints, and its genesis, in an article and would also like to
> > have the opinions of the Django community members interested in the
> > idea:
> > 
> https://www.paulox.net/2022/10/26/about-my-proposal-for-the-django-core-sprints/
>
> -- 
> Paolo Melchiorre
>
> https://www.paulox.net
>

-- 
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/994f5282-05b0-465b-8d13-851109f985c2n%40googlegroups.com.

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.