Welcome Mariusz Felisiak to his first day as a Django Fellow

[Brian Moloney]

On behalf of the Django Software Foundation, the DSF Fellowship Committee 
would like to give a shout out and a warm welcome to Mariusz on his first 
day as a Django Fellow.

We are excited to have you in the Fellowship program, Maruisz  Thank you 
for your efforts to date and efforts to come!

Warmly,

Brian Moloney
DSF Fellowship Committee

-- 
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 post to this group, send email to django-developers@googlegroups.com.
Visit this group at https://groups.google.com/group/django-developers.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/4d3c5684-b779-482a-88f5-9ee152ba642c%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

GSoC Proposal

[Marcio Bernardes]

Hi! My name is Márcio, I am 22 years old from Brazil. I know this is the 
first time I am posting here, but I hope it's the first of many. So 
attached with this message there is a proposal for the GSoC. This is based 
on the suggestions one, any thoughts? Oh yeah, I am a software developer, I 
worked some time in Europe with Python/Django now I think it's time to help 
here too. :) 

-- 
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 post to this group, send email to django-developers@googlegroups.com.
Visit this group at https://groups.google.com/group/django-developers.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/a1bce525-e6f7-48be-a573-5a27b194ea49%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.


Proposal.pdf
Description: Adobe PDF document

Re: GSoC Proposal

[vineeth sagar]

You need to be a student at a uni to be eligible for Gsoc. Hope you know
that as you say you're a Software developer.

On Mon, 18 Mar, 2019, 21:20 Marcio Bernardes, 
wrote:

> Hi! My name is Márcio, I am 22 years old from Brazil. I know this is the
> first time I am posting here, but I hope it's the first of many. So
> attached with this message there is a proposal for the GSoC. This is based
> on the suggestions one, any thoughts? Oh yeah, I am a software developer, I
> worked some time in Europe with Python/Django now I think it's time to help
> here too. :)
>
> --
> 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 post to this group, send email to django-developers@googlegroups.com.
> Visit this group at https://groups.google.com/group/django-developers.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/django-developers/a1bce525-e6f7-48be-a573-5a27b194ea49%40googlegroups.com
> 
> .
> For more options, visit https://groups.google.com/d/optout.
>

-- 
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 post to this group, send email to django-developers@googlegroups.com.
Visit this group at https://groups.google.com/group/django-developers.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/CAMMZq8MU3yuKdECJ5N_EFbWTgiiZvF7emWwned-vcxUh6nM-Lg%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: GSoC Proposal

[Marcio Bernardes]

Yes I know, and I am a student... It's all in the file.

Em segunda-feira, 18 de março de 2019 13:15:04 UTC-3, vineeth sagar 
escreveu:
>
> You need to be a student at a uni to be eligible for Gsoc. Hope you know 
> that as you say you're a Software developer.
>
> On Mon, 18 Mar, 2019, 21:20 Marcio Bernardes,  > wrote:
>
>> Hi! My name is Márcio, I am 22 years old from Brazil. I know this is the 
>> first time I am posting here, but I hope it's the first of many. So 
>> attached with this message there is a proposal for the GSoC. This is based 
>> on the suggestions one, any thoughts? Oh yeah, I am a software developer, I 
>> worked some time in Europe with Python/Django now I think it's time to help 
>> here too. :) 
>>
>> -- 
>> 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-develop...@googlegroups.com .
>> To post to this group, send email to django-d...@googlegroups.com 
>> .
>> Visit this group at https://groups.google.com/group/django-developers.
>> To view this discussion on the web visit 
>> https://groups.google.com/d/msgid/django-developers/a1bce525-e6f7-48be-a573-5a27b194ea49%40googlegroups.com
>>  
>> 
>> .
>> For more options, visit https://groups.google.com/d/optout.
>>
>

-- 
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 post to this group, send email to django-developers@googlegroups.com.
Visit this group at https://groups.google.com/group/django-developers.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/57592323-4af3-460b-8274-71b70bda0730%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: GSoC Proposal

[Adam Johnson]

Hey Marcio,

A cross-DB JSONField is something I'd like to see too, nice proposal. I
maintain the MySQL compatible field in Django-MySQL.

You wrote in the proposal that SQLite doesn't support JSON, but it does
with the json1 extension: https://www.sqlite.org/json1.html

Also I don't think it's necessarily feasible to replace the
contrib.postgres field with the unified one; it's likely that some features
won't be able to map to the "unified" model exactly. Probably easier to
leave the contrib.postgres one in there and provide migration advice to
users in the documentation.

Anyway, nice to see this as a proposal!

On Mon, 18 Mar 2019 at 16:26, Marcio Bernardes 
wrote:

> Yes I know, and I am a student... It's all in the file.
>
> Em segunda-feira, 18 de março de 2019 13:15:04 UTC-3, vineeth sagar
> escreveu:
>>
>> You need to be a student at a uni to be eligible for Gsoc. Hope you know
>> that as you say you're a Software developer.
>>
>> On Mon, 18 Mar, 2019, 21:20 Marcio Bernardes, 
>> wrote:
>>
>>> Hi! My name is Márcio, I am 22 years old from Brazil. I know this is the
>>> first time I am posting here, but I hope it's the first of many. So
>>> attached with this message there is a proposal for the GSoC. This is based
>>> on the suggestions one, any thoughts? Oh yeah, I am a software developer, I
>>> worked some time in Europe with Python/Django now I think it's time to help
>>> here too. :)
>>>
>>> --
>>> 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-develop...@googlegroups.com.
>>> To post to this group, send email to django-d...@googlegroups.com.
>>> Visit this group at https://groups.google.com/group/django-developers.
>>> To view this discussion on the web visit
>>> https://groups.google.com/d/msgid/django-developers/a1bce525-e6f7-48be-a573-5a27b194ea49%40googlegroups.com
>>> 
>>> .
>>> For more options, visit https://groups.google.com/d/optout.
>>>
>> --
> 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 post to this group, send email to django-developers@googlegroups.com.
> Visit this group at https://groups.google.com/group/django-developers.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/django-developers/57592323-4af3-460b-8274-71b70bda0730%40googlegroups.com
> 
> .
> For more options, visit https://groups.google.com/d/optout.
>


-- 
Adam

-- 
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 post to this group, send email to django-developers@googlegroups.com.
Visit this group at https://groups.google.com/group/django-developers.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/CAMyDDM1CKu-Mv9c1H_zncx6_yeHBTSdFznQQak%2BAE%2Bs4MY%2BOGg%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: Welcome Mariusz Felisiak to his first day as a Django Fellow

[Adam Johnson]

Welcome Mariusz! 

On Mon, 18 Mar 2019 at 15:38, Brian Moloney  wrote:

> On behalf of the Django Software Foundation, the DSF Fellowship Committee
> would like to give a shout out and a warm welcome to Mariusz on his first
> day as a Django Fellow.
>
> We are excited to have you in the Fellowship program, Maruisz  Thank you
> for your efforts to date and efforts to come!
>
> Warmly,
>
> Brian Moloney
> DSF Fellowship Committee
>
> --
> 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 post to this group, send email to django-developers@googlegroups.com.
> Visit this group at https://groups.google.com/group/django-developers.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/django-developers/4d3c5684-b779-482a-88f5-9ee152ba642c%40googlegroups.com
> 
> .
> For more options, visit https://groups.google.com/d/optout.
>
-- 
Adam

-- 
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 post to this group, send email to django-developers@googlegroups.com.
Visit this group at https://groups.google.com/group/django-developers.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/CAMyDDM2U5f4gGEtYGM1iic7jUsvm-wvjeC83dd9dLvCfHKV%2BBg%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: Optimization for get_search_results() in admin

[Adam Johnson]

Hi,

I've also seen this behaviour before at YPlan, we sometimes got the "mysql
can't join more than 61 tables" error or had the database slow to a crawl.
Some of the admin classes required custom get_search_results functions to
fix this.

I have only skimmed the old tickets and PR's but I think that a breaking
change to subtly changing the search behaviour is worth it to prevent this
footgun of doom is a good compromise.

Adam


On Tue, 5 Mar 2019 at 19:35, Joel M  wrote:

> I don't know whether anyone will see this, as it's my first time posting
> here, but I have to second this.
>
> This problem brought down our site yesterday when an unsuspecting admin
> user tried a 3-word search in an admin that had several search fields
> involving joins. The result was that the number of joins was multiplied by
> the number of search terms. The database machine literally ran out of space
> making the temporary table (it had been about 10% full -- this query
> occupied many times the size of the entire database), and crashed
> everything. It works fine with just 1 word. As a workaround, we blocked
> nonessential users from being able to make that search and will be removing
> less-important fields from the search_fields in a future code update. But
> it took awhile to figure out what the problem was, and this could happen in
> any admin with enough related search fields or search terms. Eventually, I
> came up with the same fix petros suggests in their PR.
>
> I know there may be users who expect the previous query behavior, but this
> is a gotcha that can hide for awhile before somebody accidentally breaks
> everything.
>
> More related tickets: https://code.djangoproject.com/ticket/16063 (with a
> similar solution), https://code.djangoproject.com/ticket/27864 (mitigate
> by limiting number of search terms)
>
> On Friday, September 23, 2016 at 1:49:14 PM UTC-4, petros.m...@gmail.com
> wrote:
>>
>> Hello,
>>
>> I would like to open a discussion on the change I have proposed with pull
>> request #7277 .
>>
>> To bring the discussion here, the problem with current implementation of
>> get_search_results() is that, when search fields include fields through
>> reverse relationships, it produces queries that the more words are used in
>> the search term the more inefficient they are. This inefficiency comes from
>> duplicate left joins with same tables which are in that case introduced by
>> Django ORM. There have been relevant reports by others before, which you
>> can see in tickets #16603 
>>  and #25789 . However,
>> judging by the fact that for five years there has not been a solution for
>> this, it seems that it is not an easy fix.
>>
>> That said, this inefficiency can easily get the system down, as users in
>> the admin can use a few words in the search term, either deliberately or by
>> mistake, e.g. by accidentally copying & pasting a whole sentence or
>> paragraph. In my case, with just 3 words in the search term and 4 tables
>> involved in the search (with their size being in the range of 1500 to 4000
>> rows), the query had been running for 25 minutes before I actually killed
>> it on the database server. Evenmore, the impact of that inefficiency can be
>> easily multiplied as users are not that patient and tend to repeat the
>> search again and again when they see that they are not getting results fast
>> enough.
>>
>> So, I wrote a small patch which changes the way the query is built and,
>> happily, the problem is gone. However, as Simon Charette has pointed out in
>> the pull request's discussion, there is the corner case scenario in which
>> some results may not be returned.
>> I am quoting his exact words:
>>
>> Keep in mind that filter(or_queries[0] & or_queries[1] & ... &
>>> or_queries[n]) can generate different results from
>>> filter(or_queries[0]).filter(or_queries[1]).filter(...).filter(or_queries[n])
>>> if any of filters spans multi-valued relationships.
>>> For example, given models Book and Author and a AuthorAmin searching
>>> both books__title and books__description your solution could filter out
>>> results that use to be displayed as search terms will have to be present in
>>> both Book.title and Book.description to match.
>>
>>
>> So, the question is whether that behavior is absolutely necessary for
>> searches in the admin. I personally believe that the compromise is small
>> enough and the benefit is really great. We are eliminating a possibility
>> for our normal users to cause a denial of service through a simple search
>> in the admin, with just a little compromise on the powerfulness of the
>> search function. What are your thoughts?
>>
> --
> 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, 

Re: help regarding google summer of code

[Confi Yobo]

Sincerely, i really think django should have an integration for
frontend frameworks just like laravel(which with just eject you have
switched framework) or ruby. because the work around  is really
stressfull and sometimes hard to deploy.

On Sat, Mar 9, 2019 at 2:48 PM Muhammad Faraz
 wrote:
>
> in it its not clear that weather its worth working and also i agree to point 
> that django is lacking in integration  with frontend frameworks like laravel 
> and ruby and also i am not focusing on only vuejs it was only because right 
> now i have worked only on vuejs so what are your thoughts on this idea and a 
> little favor can i get guide to be accepted in django part of google summer 
> of code
>
> On Saturday, March 9, 2019 at 2:30:44 PM UTC+5, Carlton Gibson wrote:
>>
>> Hi Muhammad.
>>
>> There was a thread about this the other day:
>>
>> https://groups.google.com/d/topic/django-developers/KVAZkRCq9KU/discussion
>>
>> Have a read. (Check out Aymeric's blog post series linked in that thread.)
>>
>> Work around Django's staticfiles app would be good. It would ideally be 
>> general purpose, rather than just targeting one JS framework. (i.e. not just 
>> Vue.)
>>
>> Kind Regards,
>>
>> Carlton
>>
>>
>> On Saturday, 9 March 2019 04:05:56 UTC+1, Muhammad Faraz wrote:
>>>
>>> i am taking part first time in any open source project using summer of code 
>>> and i was think would the idea of integration django with front ends like 
>>> vuejs will it be acceptable front end support especially  for vuejs is 
>>> great in laravel due to watch package so i was thinking would proposal of 
>>> creating module that make the integration of font end frame works with 
>>> django easy will it be acceptable ?
>
> --
> 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 post to this group, send email to django-developers@googlegroups.com.
> Visit this group at https://groups.google.com/group/django-developers.
> To view this discussion on the web visit 
> https://groups.google.com/d/msgid/django-developers/5240ab50-ad65-4128-808c-4c60110b482c%40googlegroups.com.
> For more options, visit https://groups.google.com/d/optout.

-- 
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 post to this group, send email to django-developers@googlegroups.com.
Visit this group at https://groups.google.com/group/django-developers.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/CAD9uRzd7rOdKqjWzGLQanMbfxVSn1ukCvkciyS3Acnr23Q9-Qg%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: Welcome Mariusz Felisiak to his first day as a Django Fellow

[Carlton Gibson]

 Welcome aboard Mariusz! 

-- 
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 post to this group, send email to django-developers@googlegroups.com.
Visit this group at https://groups.google.com/group/django-developers.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/7ec12b7d-7541-43a2-aeec-575382ffba7e%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: GSoC Proposal

[Tim Graham]

Your proposal should be quite a bit more detailed. See 
https://gist.github.com/chrismedrela/82cbda8d2a78a280a129 for a past 
example. I'm not sure if it'll be feasible to write a successful 
application without having some experience contributing to Django -- I 
think most if not all past students have had experience contributing to 
Django.

On Monday, March 18, 2019 at 11:50:34 AM UTC-4, Marcio Bernardes wrote:
>
> Hi! My name is Márcio, I am 22 years old from Brazil. I know this is the 
> first time I am posting here, but I hope it's the first of many. So 
> attached with this message there is a proposal for the GSoC. This is based 
> on the suggestions one, any thoughts? Oh yeah, I am a software developer, I 
> worked some time in Europe with Python/Django now I think it's time to help 
> here too. :) 
>

-- 
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 post to this group, send email to django-developers@googlegroups.com.
Visit this group at https://groups.google.com/group/django-developers.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/c17284b6-cb5f-4d82-8186-9b3d9484aa9e%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: Django 2.1 default of samesite=Lax for Session and CSRF cookies cause issues on Safari 12

[Mat Gadd]

You're correct that is how they rewrite the URLs, but I did know that and 
expect that to be the case.

> On 18 Mar 2019, at 17:35, René Fleschenberg  wrote:
> 
> Hi.
> 
> On 3/18/19 12:26 PM, Mat Gadd wrote:
>> Weirdly, it appears that Gmail isn't inserting click tracking for the
>> plain password reset link, but when I use my own URL shortener, I can
>> also see the google.com  redirect in play. It may
>> just be dev tools behaving strangely, or perhaps Google have tried to
>> avoid adding their tracker for password reset links. Who knows!
> 
> I did not take the time to analyze this as thoroughly as I should have,
> but from a cursory look, it seemed to me that Gmail rewrites the links
> using Javascript, and only when you click on them. Could that explain
> why your observations?
> 
> -- 
> René
> 
> -- 
> 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 post to this group, send email to django-developers@googlegroups.com.
> Visit this group at https://groups.google.com/group/django-developers.
> To view this discussion on the web visit 
> https://groups.google.com/d/msgid/django-developers/0e45692d-1974-25ff-c938-f4770f8ee786%40fleschenberg.net.
> For more options, visit https://groups.google.com/d/optout.

-- 
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 post to this group, send email to django-developers@googlegroups.com.
Visit this group at https://groups.google.com/group/django-developers.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/BB00AC09-0E6A-4568-9345-F647A04D9D94%40gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: GSoC Proposal

[Marcio Bernardes]

Hey Adam, nice to hear from you! I know this module, good work! About the 
SQLite pretty cool that they implemented this, I was not updated about it, 
this is better since they already have a certain way to do the job. About 
the documentation, this is probably the right approach, thanks for the 
feedback.

Tim, thanks for the advice, will work on that. I was afraid of this, but it 
makes total sense. I will start getting more engaged in the project from 
now on, but I'm still new in the open-source world, there's a lot of 
information, but thanks for the response anyway.

Cheers!
Em segunda-feira, 18 de março de 2019 12:50:34 UTC-3, Marcio Bernardes 
escreveu:
>
> Hi! My name is Márcio, I am 22 years old from Brazil. I know this is the 
> first time I am posting here, but I hope it's the first of many. So 
> attached with this message there is a proposal for the GSoC. This is based 
> on the suggestions one, any thoughts? Oh yeah, I am a software developer, I 
> worked some time in Europe with Python/Django now I think it's time to help 
> here too. :) 
>

-- 
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 post to this group, send email to django-developers@googlegroups.com.
Visit this group at https://groups.google.com/group/django-developers.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/c717347a-ddbc-4ef8-a259-4acb21791f8d%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

FetchFromCacheMiddleware.process_request() refactoring proposal

[Alexey Tsivunin]

https://github.com/django/django/blob/418263c457636d3301f2068c47f09a0f42e15c52/django/middleware/cache.py#L127

I have an idea how to improve readability of this method. I've already 
implemented
it but before creating an issue and PR I decided to discuss it with 
community. Maybe
all of this doesn't really have any sense.

I propose to change this code:

136 # try and get the cached GET response
137 cache_key = get_cache_key(request, self.key_prefix, 'GET', cache=
self.cache)
138 if cache_key is None:
139 request._cache_update_cache = True
140 return None  # No cache information available, need to rebuild.
141 response = self.cache.get(cache_key)
142 # if it wasn't found and we are looking for a HEAD, try looking 
just for that
143 if response is None and request.method == 'HEAD':
144 cache_key = get_cache_key(request, self.key_prefix, 'HEAD', 
cache=self.cache)
145 response = self.cache.get(cache_key)
146
147 if response is None:
148 request._cache_update_cache = True
149 return None # No cache information available, need to rebuild.



On this code:

136 vary_headers = get_cached_vary_headers(request)
137 if vary_headers is None:
138 # Vary headers for this request was not cached,
139 # so there is no cache for both GET and HEAD requests
140 # and cache should be updated
141 request._cache_update_cache = True
142 return None
143
144 cached_response = None
145
146 if request.method == 'GET':
147 cached_response = get_cached_response(request, vary_headers, 
'GET', self.key_prefix, self.cache)
148
149 if request.method == 'HEAD':
150 # HEAD request can use GET and HEAD responses both
151 # because web servers should delete body when sending HEAD 
response
152 cached_response = get_cached_response(request, vary_headers, 
'GET', self.key_prefix, self.cache) or \
153   get_cached_response(request, vary_headers, 
'HEAD', self.key_prefix, self.cache)
154
155 if cached_response is None:
156 request._cache_update_cache = True
157 return None  # No cache information available, need to rebuild.



Why? I will try to explain it by examples of questions that I had while 
reading
this code.

Let's look at the line 140. What does get_cache_key() do? Let's suppose 
it generates
key for given request and also takes into account the http method.
If so, what does it mean when cache_key is None? In according to 
comment on 140 line,
None means that cache doesn't have the response for this request and 
method.
Then why we don't check if cache_key is None after 144 line?

If None value of cache_key means that cache doesn't have the response 
for given request,
therefore not-None value means that cache has response. If so, why do 
we check
if response is None on 143 line?

I suspect the problem of this code is that it tries to hide one 
implementation
detail inside get_cache_key(). This detail is caching vary headers for the 
request.
get_cache_key(), at first, tries to get these headers and if there are none 
of them
it returns None that means there is no cache satisfying given request. But 
if
there are these headers get_cache_key() just generates key taking into
account request, method and headers. But generated key doesn't mean that
cache actually has something for this key.

I suspect that refactored code can answer all of these questions above, and 
looks
more readable, clear and explicit.

So what do you think about it?

-- 
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 post to this group, send email to django-developers@googlegroups.com.
Visit this group at https://groups.google.com/group/django-developers.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/056cecfe-979f-4662-988c-0378669c498c%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: Django 2.1 default of samesite=Lax for Session and CSRF cookies cause issues on Safari 12

[René Fleschenberg]

Hi.

On 3/18/19 12:26 PM, Mat Gadd wrote:
> Weirdly, it appears that Gmail isn't inserting click tracking for the
> plain password reset link, but when I use my own URL shortener, I can
> also see the google.com  redirect in play. It may
> just be dev tools behaving strangely, or perhaps Google have tried to
> avoid adding their tracker for password reset links. Who knows!

I did not take the time to analyze this as thoroughly as I should have,
but from a cursory look, it seemed to me that Gmail rewrites the links
using Javascript, and only when you click on them. Could that explain
why your observations?

-- 
René

-- 
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 post to this group, send email to django-developers@googlegroups.com.
Visit this group at https://groups.google.com/group/django-developers.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/0e45692d-1974-25ff-c938-f4770f8ee786%40fleschenberg.net.
For more options, visit https://groups.google.com/d/optout.

Re: Django 2.1 default of samesite=Lax for Session and CSRF cookies cause issues on Safari 12

[Flávio Junior]

Hey Mat, thanks for the input. Good to know SESSION_COOKIE_SAMESITE = None 
and CSRF_COOKIE_SAMESITE = None solved the issue 29975. Do you want to post 
there this solution? I can do it to.
I've updated safari-samesite-cookie-issue 
 to better 
reproduce the session issue too.

Florian, I didn't know about Safari Technology Preview, thanks! Installed 
it in my Mac Mojave 10.14.3. Tested again 
my safari-samesite-cookie-issue project. Issue seems solved.
My Safari is "Release 77 (Safari 12.2, WebKit 14608.1.7.3)".

Good to know it's a matter of time until this issue is solved in the wild. 
But I still think it's a serious problem: it caused us a major disruption 
in production because our transactions are very email-based, and therefore 
rely on third-party redirects.

What are the next steps?
A warning at the docs for these settings?
Happy to help if necessary.

On Monday, March 18, 2019 at 2:38:13 PM UTC-3, Mat Gadd wrote:
>
> You're correct that is how they rewrite the URLs, but I did know that and 
> expect that to be the case. 
>
> > On 18 Mar 2019, at 17:35, René Fleschenberg  > wrote: 
> > 
> > Hi. 
> > 
> > On 3/18/19 12:26 PM, Mat Gadd wrote: 
> >> Weirdly, it appears that Gmail isn't inserting click tracking for the 
> >> plain password reset link, but when I use my own URL shortener, I can 
> >> also see the google.com  redirect in play. It may 
> >> just be dev tools behaving strangely, or perhaps Google have tried to 
> >> avoid adding their tracker for password reset links. Who knows! 
> > 
> > I did not take the time to analyze this as thoroughly as I should have, 
> > but from a cursory look, it seemed to me that Gmail rewrites the links 
> > using Javascript, and only when you click on them. Could that explain 
> > why your observations? 
> > 
> > -- 
> > René 
> > 
> > -- 
> > 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-develop...@googlegroups.com . 
> > To post to this group, send email to django-d...@googlegroups.com 
> . 
> > Visit this group at https://groups.google.com/group/django-developers. 
> > To view this discussion on the web visit 
> https://groups.google.com/d/msgid/django-developers/0e45692d-1974-25ff-c938-f4770f8ee786%40fleschenberg.net.
>  
>
> > For more options, visit https://groups.google.com/d/optout. 
>
>

-- 
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 post to this group, send email to django-developers@googlegroups.com.
Visit this group at https://groups.google.com/group/django-developers.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/76e3cf08-2c4c-4690-84e7-38eed0abb773%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: FetchFromCacheMiddleware.process_request() refactoring proposal

[Adam Johnson]

Well, it might not be the most valuable thing to work on, but if it helps
you get comfortable with the code base and the changes are low to zero
risk, it’s not so bad. I think there might be a smaller set of changes that
reduces the risk.

On Mon, 18 Mar 2019 at 23:08, Alexey Tsivunin  wrote:

> Thanks for your feedback! I'll make a PR in the coming days. I just needed
> to know does anyone else think this code needs refactoring or I'm doing
> useless work.
>
> --
> 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 post to this group, send email to django-developers@googlegroups.com.
> Visit this group at https://groups.google.com/group/django-developers.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/django-developers/d077dd35-39e1-48a4-907e-6c488926f95a%40googlegroups.com
> 
> .
> For more options, visit https://groups.google.com/d/optout.
>
-- 
Adam

-- 
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 post to this group, send email to django-developers@googlegroups.com.
Visit this group at https://groups.google.com/group/django-developers.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/CAMyDDM3QGt4XLm6NRvc_k78SqkSjxO_KvuNLEvYAu3TdGGvzpA%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: FetchFromCacheMiddleware.process_request() refactoring proposal

[Adam Johnson]

Hi

I appreciate the enthusiasm! Making Django's code more readable is
certainly a good goal, but refactoring must be done very carefully as we
don't want to avoid subtle bugs, especially in a function that's directly
used by users.

This mailing list is generally not for low level code discussions, but for
higher level design and directional decisions. You're better off making the
change, testing it, and then opening a PR for refactoring like this. It's
easier to comment on the code there, especially since it can be seen as
code diffs, and more convincing to see it done with the test suite passing
:) Normally one of the fellows will get back to you first on a PR - if you
or they are unsure about the change, you can always post to the mailing
list asking people to look at the PR.

As for your query: get_cache_key is documented as:

get_cache_key(request, key_prefix=None)[source]
> Returns a cache key based on the request path. It can be used in the
> request phase because it pulls the list of headers to take into account
> from the global path registry and uses those to build a cache key to check
> against.
>
> If there is no headerlist stored, the page needs to be rebuilt, so this
> function returns None.


As far as I can tell you're right that cache_key should really be checked
for None on current line 144. The cache could lose the cached headerlist
value between the two calls to get_cache_key - that said it wouldn't affect
things too badly as all that would happen is the next request would see the
response as not cached, even though it would have been.

As for the more major refactoring work to extract the cached vary headers,
you'd need to modify django.utils.cache to make the internals of some of
the functions public for this, since it is a public API. Any changes must
be done carefully as users depend on that code. I'm not sure if the changes
you're proposing would be compatible without deeper inspection, but also
seeing a PR would help, as per reasons above :)

Hope that helps,

Adam



On Mon, 18 Mar 2019 at 21:30, Alexey Tsivunin  wrote:

>
> https://github.com/django/django/blob/418263c457636d3301f2068c47f09a0f42e15c52/django/middleware/cache.py#L127
>
> I have an idea how to improve readability of this method. I've already
> implemented
> it but before creating an issue and PR I decided to discuss it with
> community. Maybe
> all of this doesn't really have any sense.
>
> I propose to change this code:
>
> 136 # try and get the cached GET response
> 137 cache_key = get_cache_key(request, self.key_prefix, 'GET', cache=
> self.cache)
> 138 if cache_key is None:
> 139 request._cache_update_cache = True
> 140 return None  # No cache information available, need to
> rebuild.
> 141 response = self.cache.get(cache_key)
> 142 # if it wasn't found and we are looking for a HEAD, try looking
> just for that
> 143 if response is None and request.method == 'HEAD':
> 144 cache_key = get_cache_key(request, self.key_prefix, 'HEAD',
> cache=self.cache)
> 145 response = self.cache.get(cache_key)
> 146
> 147 if response is None:
> 148 request._cache_update_cache = True
> 149 return None # No cache information available, need to rebuild.
>
>
>
> On this code:
>
> 136 vary_headers = get_cached_vary_headers(request)
> 137 if vary_headers is None:
> 138 # Vary headers for this request was not cached,
> 139 # so there is no cache for both GET and HEAD requests
> 140 # and cache should be updated
> 141 request._cache_update_cache = True
> 142 return None
> 143
> 144 cached_response = None
> 145
> 146 if request.method == 'GET':
> 147 cached_response = get_cached_response(request, vary_headers,
> 'GET', self.key_prefix, self.cache)
> 148
> 149 if request.method == 'HEAD':
> 150 # HEAD request can use GET and HEAD responses both
> 151 # because web servers should delete body when sending HEAD
> response
> 152 cached_response = get_cached_response(request, vary_headers,
> 'GET', self.key_prefix, self.cache) or \
> 153   get_cached_response(request, vary_headers,
> 'HEAD', self.key_prefix, self.cache)
> 154
> 155 if cached_response is None:
> 156 request._cache_update_cache = True
> 157 return None  # No cache information available, need to
> rebuild.
>
>
>
> Why? I will try to explain it by examples of questions that I had while
> reading
> this code.
>
> Let's look at the line 140. What does get_cache_key() do? Let's
> suppose it generates
> key for given request and also takes into account the http method.
> If so, what does it mean when cache_key is None? In according to
> comment on 140 line,
> None means that cache doesn't have the response for this request and
> method.
> Then why we don't check if cache_key is None after 144 line?
>
> If None value of cache_key means that cache 

Re: FetchFromCacheMiddleware.process_request() refactoring proposal

[Alexey Tsivunin]

Thanks for your feedback! I'll make a PR in the coming days. I just needed 
to know does anyone else think this code needs refactoring or I'm doing 
useless work.

-- 
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 post to this group, send email to django-developers@googlegroups.com.
Visit this group at https://groups.google.com/group/django-developers.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/d077dd35-39e1-48a4-907e-6c488926f95a%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: GSoC 2019 proposal - Easy Ethereum Blockchain integration

[Carlton Gibson]

Hi Diego. 

Thanks for your interest. 

> So my idea falls out of scope? Did I make a mistake?

I think there's a difference in kind between e.g. South and Django Debug 
Toolbar (or even things like Django Extenstions, or Braces or Model Utils) 
which support development with Django and your proposal which is more *building 
a feature in Django*. ("with" vs "in") Hopefully that distinction is clear 
enough for here and now. 

It's not that all "in" type third-party suggestion would be out of scope — 
I could imagine a good proposal for 2FA and One-time-passwords being at 
least considered, even if preferred as a third-party app, for example — but 
I think yes, "Using Blockchain in Django" is out of scope for us for GSoC. 

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 post to this group, send email to django-developers@googlegroups.com.
Visit this group at https://groups.google.com/group/django-developers.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/fdf957e6-b3f2-4625-9c36-2931f5734526%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Django 2.2 release candidate 1 released

[Carlton Gibson]

We've made the final (hopefully) release on the way to Django's next 
major release, Django 2.2! Check out the blog post: 
https://www.djangoproject.com/weblog/2019/mar/18/django-22-rc1/

-- 
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 post to this group, send email to django-developers@googlegroups.com.
Visit this group at https://groups.google.com/group/django-developers.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/0606040C-D01D-4BFD-956C-2663DCAE7BF2%40gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: GSOC 19 PROPOSAL IDEA

[Carlton Gibson]

Hi Chinmay. 

Thanks for your interest. A 13 year old ticket would certainly be a 
nice-to-close. 

Some quick thoughts: 


   1. We're close to the deadline here, so can you turn this into a final 
   proposal? (Look at the example for a previous 
   year: https://gist.github.com/chrismedrela/82cbda8d2a78a280a129 — we need 
   something like this.) 
   2. You've begun well telling us who you are. But tell us more in your 
   proposal. We don't know you already and need to be confident that you'd be 
   likely to succeed in your project. 
   3. We already use select2 for the autocomplete in the 
   admin. https://select2.org. This would integrate well with that by the 
   looks of it. 
   4. Would this take 12 weeks? If not there are lots of Admin tickets 
   

 — 
   I'm sure we can help find some, but any related target ticket you identify 
   are all for the good. 

Time is short here. :)

Kind Regards,

Carlton


On Thursday, 14 March 2019 01:03:33 UTC+1, Chinmay Relkar wrote:
>
> Hi,
>My name is Chinmay Relkar. I'm a final year undergrad from India. 
> This is about my GSOC proposal idea. 
>
>While playing with django, I've always come across the absence of 
> bidirectional ManyToMany feature ticketed at
> *code.djangoproject.com/ticket/897 
> *. 
> I would like to work on this feature as a part of the GSOC program. 
> 
>To me this feature feels a bit small for a 12 week program. So 
> here's something I would like to add on:
>
> While adding a Model item in the admin interface with a ManyToMany 
> field, we get a MultiSelectWindow to choose multiple items of the related 
> model. This UI isn't very intuitive.
> 
> Taking inspiration from the Chips Component defined in Material Design 
> Guidelines at *https://material.io/design/components/chips.html 
> * I would like to 
> implement FilterChip for the same multi select window. The example of which 
> is attached below. 
>
> This is not a final proposal. I hope I'm not too late to share this here. 
>
> I'm eagerly waiting for a response of feedback and suggestions. 
>
> About my experience with Django, I've been working with it for past 2 
> years. Completed a total of 3 projects, one of which is live at *acsinet.net 
> * with a heavily customised admin panel.
>
> Talking about my level of expertise, I'm not a master to be true. But I 
> can customise any component of Django according to the stated requirements. 
> This is a very rough sketch of the proposal. Any suggestions, remarks or 
> comments will be of great help. 
>
> Hoping to get a feedback soon. 
>
> Regards,
> Chinmay Relkar
>

-- 
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 post to this group, send email to django-developers@googlegroups.com.
Visit this group at https://groups.google.com/group/django-developers.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/93cfee50-72be-4068-b700-dccc5d932b88%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Google "Season of Docs"

[Carlton Gibson]

Hi all, 

Parallel to GSoC, Google now have this "Season of Docs" programme: 

https://developers.google.com/season-of-docs/

The idea is experienced technical writers can get funding to work with open 
source projects on their docs. 

There are a lot of open Documentation issues 

. 

As such if you have, or if you know someone with, strong writing skills and 
you 
(they) might be interested here let me know and we can look into this. 

I can't quite work out whether if we just apply we might attract a writer, 
but it would be 
awesome if already someone in the community was keen for this.

Thanks. 

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 post to this group, send email to django-developers@googlegroups.com.
Visit this group at https://groups.google.com/group/django-developers.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/34c05950-079b-4d64-a4f8-6dfcbf7f624d%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: Django 2.1 default of samesite=Lax for Session and CSRF cookies cause issues on Safari 12

[Mat Gadd]

As the author of 29975, I figured I'd weigh in here.

I've set our site to use SESSION_COOKIE_SAMESITE = None and 
CSRF_COOKIE_SAMESITE = None and tested password reset links with and without 
click tracking (in additional to Gmail's tracking), and it certainly appears to 
fix the issue with Safari on macOS and iOS for me.

Weirdly, it appears that Gmail isn't inserting click tracking for the plain 
password reset link, but when I use my own URL shortener, I can also see the 
google.com  redirect in play. It may just be dev tools 
behaving strangely, or perhaps Google have tried to avoid adding their tracker 
for password reset links. Who knows!

> On 15 Mar 2019, at 14:38, Florian Apolloner  wrote:
> 
> Hi Flavio,
> 
> On Friday, March 15, 2019 at 2:56:16 PM UTC+1, Flávio Junior wrote:
> > shouldn't httponly yes/no control whether JS can read the data?
> 
> Yes. But, on Django, the default is httponly false for CSRF cookie. 
> So even without httponly, Safari doesn't allow JS to read the CSRF cookie. 
> Safari also doesn't send the session cookie nor the CSRF cookie during the 
> request (if it comes from a cross-site source, like an email tracker 
> redirection). 
> 
> Oh sorry I was being unclear here. What I wanted to say/ask is whether you 
> had set httponly because I couldn't imagine the SameSite policy to affect 
> that. Thanks for clearing that up.
> 
>  
> > I am wondering if this also results in 
> > https://code.djangoproject.com/ticket/29975 
> > 
> >  or if this is just a result of their tracking protection
> 
> Yes, I think it's the same problem. I don't think this is a result of the 
> "Protection Against First Party Bounce Trackers" because the issue don't 
> happens if SESSION_COOKIE_SAMESITE = None and CSRF_COOKIE_SAMESITE = None, 
> which is the behavior of Django < 2.1.
> This is an issue with Django 2.1 defaults + Safari 12 + cross-site 
> redirection.
> That's why I suggested a change on defaults, or at least some clear warning.
> 
> Interesting, it would certainly be nice if I/someone could verify this. If 
> setting the policy from lax to none also fixes the password reset issue, then 
> I am mostly in favor of a "warning" somewhere for now. I do not think that a 
> simple default change is a good idea in the long run. I'll mail you later for 
> credentials (If I don't find some lying around in the company).
> 
> As for the beta versions, is it possibly that you would only update safari or 
> would you have to update your whole iOS/macOS? Ie could you test with 
> https://developer.apple.com/safari/technology-preview/ if the issue is gone 
> again on your mac?
> 
> Cheers,
> Florian
> 
> -- 
> 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 post to this group, send email to django-developers@googlegroups.com 
> .
> Visit this group at https://groups.google.com/group/django-developers 
> .
> To view this discussion on the web visit 
> https://groups.google.com/d/msgid/django-developers/70770663-f56c-4c9c-b75b-961a1d6df964%40googlegroups.com
>  
> .
> For more options, visit https://groups.google.com/d/optout 
> .

-- 
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 post to this group, send email to django-developers@googlegroups.com.
Visit this group at https://groups.google.com/group/django-developers.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/EED22A8B-A650-4979-8C86-A75E07648864%40gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: De-assigning "Easy pickings" tickets

[Mariusz Felisiak]

Totally agree!

Best,
Mariusz

W dniu piątek, 8 marca 2019 20:30:11 UTC+1 użytkownik Carlton Gibson 
napisał:
>
> Hi all. 
>
> We don't have many Easy Pickings tickets, they're all assigned, and get 
> assigned quickly, but don't often get closed. 
>
> Looking at the current batch...
>
>
> https://code.djangoproject.com/query?status=assigned=new=1=id=status=changetime=1=changetime
>
> ... I'd like to suggest that after 2 months we de-assign them, so they can 
> get picked up by people looking, who are likely not willing/able/whatever 
> to take over an assigned ticket themselves. 
>
> Any thoughts/objections to that as a policy? 
>
> Thanks. 
>
> 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 post to this group, send email to django-developers@googlegroups.com.
Visit this group at https://groups.google.com/group/django-developers.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/944abe0a-1281-49b4-bb75-476b240fbb6d%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: De-assigning "Easy pickings" tickets

[Adam Johnson]

Non-fellow agreeing here too :)

On Mon, 18 Mar 2019 at 12:08, Mariusz Felisiak 
wrote:

> Totally agree!
>
> Best,
> Mariusz
>
> W dniu piątek, 8 marca 2019 20:30:11 UTC+1 użytkownik Carlton Gibson
> napisał:
>>
>> Hi all.
>>
>> We don't have many Easy Pickings tickets, they're all assigned, and get
>> assigned quickly, but don't often get closed.
>>
>> Looking at the current batch...
>>
>>
>> https://code.djangoproject.com/query?status=assigned=new=1=id=status=changetime=1=changetime
>>
>> ... I'd like to suggest that after 2 months we de-assign them, so they
>> can get picked up by people looking, who are likely not
>> willing/able/whatever to take over an assigned ticket themselves.
>>
>> Any thoughts/objections to that as a policy?
>>
>> Thanks.
>>
>> 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 post to this group, send email to django-developers@googlegroups.com.
> Visit this group at https://groups.google.com/group/django-developers.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/django-developers/944abe0a-1281-49b4-bb75-476b240fbb6d%40googlegroups.com
> 
> .
> For more options, visit https://groups.google.com/d/optout.
>


-- 
Adam

-- 
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 post to this group, send email to django-developers@googlegroups.com.
Visit this group at https://groups.google.com/group/django-developers.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/CAMyDDM3n4s8d-ecLLDMdP_SvGC3oLaYov26ms3dp8ZaxKV-a5Q%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: De-assigning "Easy pickings" tickets

[Carlton Gibson]

Given no dissenting voices, I'll act on this. 

I'll deassign the stalest tickets and leave a comment for more recently 
updated ones. 


-- 
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 post to this group, send email to django-developers@googlegroups.com.
Visit this group at https://groups.google.com/group/django-developers.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/1fafc83a-9034-48e9-b2d4-15141b296885%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.