Re: Stalebot on djangoproject.com issues

[Sarah Boyce]

>From what it sounds, I guess the main value was prompting a one time spring 
clean. As there are not that many issues open in djangoproject.com and all 
issues will have been re-validated, I think it makes sense to remove it to 
reduce this additional burden/frustration.

There are configurations around stale PR closing which I think makes more 
sense in general (maybe not for djangoproject.com as there are not many 
PRs), as other people might be reluctant to work on something if there is 
an open PR and it prompts someone to decide if they want to come back to 
this if they have just forgotten for example.

On Wednesday, 5 April 2023 at 23:30:54 UTC+2 Tim Graham wrote:

> Hello,
>
> In October 2022, a stalebot was activated for djangoproject.com issues:
>
> https://github.com/django/djangoproject.com/issues/1219
> https://github.com/django/djangoproject.com/pull/1220
>
> It comments on an issue if there's no activity in the last six months: "This 
> issue has been automatically marked as stale because it has not had recent 
> activity. It will be closed if no further activity occurs. Thank you for 
> your contributions."
>
> The bot closes the issue if there's no activity in the next seven days.
>
> I didn't see much discussion among the djangproject.com team outside of 
> the issue and PR,  but the rationale from the issue is this: "Idea copied 
> from DRF PR #8423 
>  - Add a 
> StaleBot, configured with the lowest possible run limit. The intent here 
> is to help us sweep through the issue and pull request backlog, and review 
> what does and does not need to remain open at this point in time."
>
> Here is what I said at the time: "I think this is a lame way to handle 
> old issues. The result seems to be Carlton triaging all issues that the bot 
> comments on. You could have asked him to do that without a bot adding 
> noise. Should a useless "issue still valid" comment be required every 180 
> days? Why not have a human triage each issue now that more people are 
> maintaining this site? Using a bot comes off to me as passive aggressive. 
> Why try to automatically discard years of issues (even if minor)? It's not 
> like the passage of time or lack of activity means the problem went away. A 
> responsible reporter will look through existing issues so they don't report 
> a duplicate and not necessarily leave a comment like "issue still valid." 
> If we close the issue automatically, what did that accomplish? I would 
> think triaging issues would be a good way for new team members to develop 
> their understanding of the site. If you're feeling unknowledgable about an 
> old issue, feel free to ping me for advice. I hope you might reconsider the 
> usefulness of the bot."
>
> It's six months later, and I'm now having to again comment on inactive 
> issues "stalebot, please don't close." to keep valid issues open.
>
> Paolo Melchiorre (author of this initiative) says, "activating the 
> stalebot last year allowed us to close many old issues. I think an issue 
> opened 7 years ago should be closed if no one takes care of it despite two 
> reminders in the last year. As the removal of the stalebot is not only up 
> to me, I think it is worth discussing it in a separate issue or on the 
> developer mailing list."
>
> I remain of the opinion that continued attempts to automatically abandon 
> valid issues are not helpful and do not reflect project maintenance best 
> practices. I would like to hear your thoughts on the matter. Thanks!
>

-- 
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/0fbe194d-2626-49c6-a91e-b8538b0ae1a6n%40googlegroups.com.

Proposal: Constructing urls outside the request cycle

[Sarah Boyce]

Hello 👋 

This is a summary of some previous discussions which need opening up to the 
group 👍

There is a need to have some kind of URL outside the request cycle (such as 
sending emails which need to create a link).
For constructing a correct MEDIA_URL / STATIC_URL we wanted to use the 
script prefix to allow for more dynamic changes (ie allow a user to move to 
a subpath without having to change multiple variables). In the request 
cycle you can use get_script_prefix() for this but outside the request 
cycle this isn't currently very achievable (see related tickets #34028 
 #16734 
).

There is a current proposal from @Florian Apolloner:
"I am really starting to lean towards introducing a setting (yes!) called 
BASE_URL that can be set to https://mysite.com/subpath. This would allow 
for a) generating URLs outside a request context and b) allow us to mostly 
ignore script prefix. We could also use a relative STATIC_URL and append it 
to BASE_URL. This way there would be just one setting that requires 
changing and many projects hopefully would make that configurable via env 
vars etc."

New settings are a little controversial, so what do you think about this 
approach? Are there any other ideas or concerns?

-- 
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/df82f370-e96a-498c-ac08-89d34d5cadd5n%40googlegroups.com.

Re: Ticket #30382 force_insert flag is not passed when saving parents on inherited models

[Sarah Boyce]

+1
Looking at the PR it looks like a boolean is still an accepted value for 
force_insert which is nice as the feature looks to be used quite a bit 
(just a rough idea 
https://github.com/search?type=code&auto_enroll=true&q=force_insert%3DTrue). 

Might be a stupid question, reading the 
docs 
https://docs.djangoproject.com/en/4.2/ref/models/instances/#ref-models-force-insert,
 
force_update is currently the opposite of force_insert. Would/should 
force_update accept the same pattern? 
On Friday, 19 May 2023 at 06:15:00 UTC+2 charettes wrote:

> I left some notes on the PR but I think the crux of the issue here is that 
> you are trying to change the meaning of Model.save(force_insert=True) from 
> force the insert of the current model to force the insert of the model and 
> all its bases.
>
> This is a problem not only for QuerySet.create but likely for a many other 
> use cases in the wild that need a way to only force the creation of the 
> leaf table but not others. In other words, the change you are proposing 
> take one feature way (only insert leaf model) to introduce a new one 
> (insert all bases) and thus is fundamentally backward incompatible.
>
> To me the only way forward here is to introduce a new feature but as 
> you've mentioned changing the signature of Model.save() is comple.
>
> The only viable option I can think of is to change the accepted type for 
> force_insert from bool to Type[Model] | Tuple[Type[Model]] to allow 
> save_parent to determine which one should be forced inserted and which 
> shouldn't.
>
> In the case of the reported usage case
>
> ```
> class ParentModel(models.Model):
> id = models.BigIntegerField(primary_key=True)
>
> class ChildModel(ParentModel): pass
> ```
>
> That would mean that force_insert=ParentModel must be passed to opt-in 
> into the full insertion mode (both issubclass(ChildModel, ParentModel) 
> and issubclass(ParentModel, ParentModel))
>
> ```
> ChildModel(id=1).save(force_insert=ParentModel)
> ```
>
> That seems  like a viable option to me because
>
> - An empty tuple is falsy which is coherent with force_insert=False
> - A non-empty tuple is truthy and which is coherent with the fact the 
> current leaf model must be inserted (current behavior)
> - Complex MTI scenario forced insertion needs can be targeted with 
> specially crafted base tuples (think of diamond inheritance)
> - If a deep ancestor must be inserted then it means that all its children 
> must also be inserted (makes sense due to how children must reference to 
> parent)
> - force_insert=models.Model can be used as a generic way to specify that 
> all bases must be inserted independently of the chain of models involved
>
> Hope that makes sense!
>
> Cheers,
> Simon
>
> Le jeudi 18 mai 2023 à 22:46:35 UTC-4, Akash Sen a écrit :
>
>> *[*Looking for an alternate approach*]*
>> *Ticket link : *https://code.djangoproject.com/ticket/30382
>>
>> *Problem : *When saving we pass force_insert=True to prevent the extra 
>> UPDATE statement that precedes the INSERT. The force_insert flag is 
>> respected on the child table but not on the parent.
>>
>> *The main problem : *On our first go this issue would seem an easy 
>> picking as we just have to pass the force_insert flag while saving the 
>> parents, but as mentioned here 
>>  it is going to 
>> create a disaster of integrity errors in the Model.objects.create() method 
>> with non-abstract inherited parents as the create method assumes 
>> force_insert=True.
>>
>> *Approach 1: *Set the force_insert=False inside create method if that 
>> contains a non-abstract parent model. 
>>
>> The problem with it is it generates an extra query while creating the non 
>> abstract child model when the parent exists, more details can be found 
>> here... 
>>  (Tried 
>> in the PR)
>>
>> *Approach 2: *Pass an extra flag to the save method and if the method 
>> call is coming from create then prevent passing force_insert flag(i.e set 
>> it to false) while saving parents when called via create, but as we cannot 
>> change the signature of the save method we cannot simply take an extra 
>> flag, so this comes down to a very simple question : 
>>
>> *How to pass a flag to a python method without changing its signature:*
>> I can think of three approaches for this,
>> 1. Inspecting a stack frame(Deprecated because of performance issues) - 
>> Tried in the PR
>> 2. Using a global variable (Deprecated because of performance issues)
>> 3. Using a class variable (Deprecated because of backward compatibility 
>> as names can collide with method, variable, property name of a model) - 
>> Tried in the PR
>>
>> *PR link :* https://github.com/django/django/pull/16830
>>
>> If someone can suggest an alternate approach that would be great!
>>
>

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers  (Con

Django bugfix releases issued: 4.2.12 and 5.0.5

[Sarah Boyce]

Details are available on the Django project weblog:
https://www.djangoproject.com/weblog/2024/may/06/bugfix-releases/

-- 
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/CAN%2BfQHyT9xZmOm6CQxbo9jv99cQinJME3n8dBiJaS%3DVpvTJovw%40mail.gmail.com.

Django security releases issued: 5.0.8 and 4.2.15

[Sarah Boyce]

Details are available on the Django project weblog:

https://www.djangoproject.com/weblog/2024/aug/06/security-releases/

-- 
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/CAN%2BfQHw4mW%3Dvg6arF-bRCU_7Zu6bHMtr%2B8BJFhAgDb20Jt9DBQ%40mail.gmail.com.

[Proposal] Add a PR template to the Django repo

[Sarah Boyce]

Hi all,

Wondering if I could get some consensus at to whether a PR template would 
be beneficial to the Django GitHub repository.

What I have in mind, would be pulling elements from the patch review 
checklist[1] to be an actual checklist[2] (perhaps in a collapsed 
section[3]) that appears on the PR itself.

Reasons I think it's not a good idea:
- we would be duplicating information in 2 places (in the docs and in the 
PR template), which would be harder to maintain.
- when creating your first PR, a comment asks you to review this checklist 
(links to the docs). So people without this comment have done it before and 
presumably read it.

Reasons I think it's a good idea:
- brings the information needed closer to the pr author, without linking 
them away
- I had "read" the checklist, and have since re-read, and there was a lot I 
hadn't taken in. I think it is still useful for after the first patch.
- I like to cross things off lists

I am on the fence as to whether it would add value or not. If we think it 
would add value, I would be happy to create a ticket in Track and raise a 
PR.

Looking forward to hearing your thoughts.
Have a wonderful day.
Sarah


Note: I can see a PR template was briefly mentioned before[4] when 
discussing adding a pre-commit but I can't mind other mentions so far. 
Sorry if it has already been discussed.


[1]: 
https://docs.djangoproject.com/en/dev/internals/contributing/writing-code/submitting-patches/#patch-review-checklist
[2]: 
https://docs.github.com/en/get-started/writing-on-github/getting-started-with-writing-and-formatting-on-github/basic-writing-and-formatting-syntax#task-lists
[3]: 
https://docs.github.com/en/get-started/writing-on-github/working-with-advanced-formatting/organizing-information-with-collapsed-sections
[4]: https://groups.google.com/g/django-developers/c/LVWssSldjVs/m/DJcheek3AgAJ

-- 
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/bc0cb58e-5366-4119-9161-c3cc5dd85012n%40googlegroups.com.

Django security releases issued: 5.1.4, 5.0.10, and 4.2.17

[Sarah Boyce]

Details are available on the Django project weblog:
https://www.djangoproject.com/weblog/2024/dec/04/security-releases/

-- 
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 visit 
https://groups.google.com/d/msgid/django-developers/CAN%2BfQHzr8Sk3QpGM5irikjOM_FkbtO%3DOC-Vmg37tuoRUba6Rug%40mail.gmail.com.

Django 5.2 alpha 1 released

[Sarah Boyce]

Details are available on the Django project weblog:
https://www.djangoproject.com/weblog/2025/jan/16/django-52-alpha-1-released/

-- 
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 visit 
https://groups.google.com/d/msgid/django-developers/CAN%2BfQHwYFSQrGd8%3DwRvBqcnwDoXotNLFSAe%3DdibcUmECRTYV5g%40mail.gmail.com.

Django 5.2 beta 1 released

[Sarah Boyce]

Details are available on the Django project weblog:
https://www.djangoproject.com/weblog/2025/feb/19/django-52-beta-1-released/

-- 
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 visit 
https://groups.google.com/d/msgid/django-developers/CAN%2BfQHwOhdmDsQRMYuSY4XYiquw_QDTdbJF2BhngTZ%3D_zL0Z1g%40mail.gmail.com.