Re: Support for unittest -k option

2019-03-11 Thread Arthur Rio
I’m +1 on no short-hand. Also “kdb” is a little to close to “pdb” and
doesn’t really make sense to me.

—
Arthur

On March 11, 2019 at 3:33:50 PM, Dan Davis (dansm...@gmail.com) wrote:

I personally don't think a short-hand is needed.

On Mon, Mar 11, 2019 at 10:41 AM Tim Graham  wrote:

> -kdb could be a suitable short option.
>
> On Monday, March 11, 2019 at 9:20:37 AM UTC-4, Tobias McNulty wrote:
>>
>> Agreed it's probably better to make the switch now, and I'd be fine
>> without a replacement shorthand alternative for --keepdb.
>>
>> Cheers,
>>
>>
>> *Tobias McNulty*Chief Executive Officer
>>
>> tob...@caktusgroup.com
>> www.caktusgroup.com
>>
>>
>> On Mon, Mar 11, 2019 at 8:19 AM Carlton Gibson 
>> wrote:
>>
>>> Thanks François,
>>>
>>> Just on this, my thought is that if we don't follow `unittest` in
>>> changing `-k` for this, we have a steady trickle of confusion forever-more.
>>> I'd rather avoid that.
>>>
>>> C.
>>>
>>> On Monday, 11 March 2019 13:14:01 UTC+1, François Freitag wrote:

 Hi Django Devs,

 https://code.djangoproject.com/ticket/30245 suggests supporting Python
 unittest `-k` option, to selectively run tests matching a keyword.

 Currently, `-k` is the shorthand for `--keepdb` in Django.
 A `--filter` flag was suggested to preserve backward compatibility.
 Carlton suggested removing the `-k` option from `--keepdb` and reusing
 it for unittest `-k`. That would follow unittest more closely, reduce
 user confusion and ease maintenance.

 What do you think is best? Do you see other options?

 If re-taking the `-k` option for unittest `-k`, should a new shorthand
 be introduced for `--keepdb`?

 Thanks for your time,
 François

>>> --
>>> 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/c54e52d2-012a-4852-9375-be37add55945%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/d0f1df05-238c-4ad6-97c2-a852bda939bc%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/CAFzonYYRhKbPbuUvZCb9hM3jM%3D90VPwv9Ug%2B0k%3DdXUuRyDMz_Q%40mail.gmail.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/CADOBPEEJGbczwxmCax0ak0p3DqSJc9K_wApbbATo_q9Ywx%3D0ug%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.


Re: Support for unittest -k option

2019-03-11 Thread Dan Davis
I personally don't think a short-hand is needed.

On Mon, Mar 11, 2019 at 10:41 AM Tim Graham  wrote:

> -kdb could be a suitable short option.
>
> On Monday, March 11, 2019 at 9:20:37 AM UTC-4, Tobias McNulty wrote:
>>
>> Agreed it's probably better to make the switch now, and I'd be fine
>> without a replacement shorthand alternative for --keepdb.
>>
>> Cheers,
>>
>>
>> *Tobias McNulty*Chief Executive Officer
>>
>> tob...@caktusgroup.com
>> www.caktusgroup.com
>>
>>
>> On Mon, Mar 11, 2019 at 8:19 AM Carlton Gibson 
>> wrote:
>>
>>> Thanks François,
>>>
>>> Just on this, my thought is that if we don't follow `unittest` in
>>> changing `-k` for this, we have a steady trickle of confusion forever-more.
>>> I'd rather avoid that.
>>>
>>> C.
>>>
>>> On Monday, 11 March 2019 13:14:01 UTC+1, François Freitag wrote:

 Hi Django Devs,

 https://code.djangoproject.com/ticket/30245 suggests supporting Python
 unittest `-k` option, to selectively run tests matching a keyword.

 Currently, `-k` is the shorthand for `--keepdb` in Django.
 A `--filter` flag was suggested to preserve backward compatibility.
 Carlton suggested removing the `-k` option from `--keepdb` and reusing
 it for unittest `-k`. That would follow unittest more closely, reduce
 user confusion and ease maintenance.

 What do you think is best? Do you see other options?

 If re-taking the `-k` option for unittest `-k`, should a new shorthand
 be introduced for `--keepdb`?

 Thanks for your time,
 François

>>> --
>>> 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/c54e52d2-012a-4852-9375-be37add55945%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/d0f1df05-238c-4ad6-97c2-a852bda939bc%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/CAFzonYYRhKbPbuUvZCb9hM3jM%3D90VPwv9Ug%2B0k%3DdXUuRyDMz_Q%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.


Re: Support for unittest -k option

2019-03-11 Thread Tim Graham
-kdb could be a suitable short option.

On Monday, March 11, 2019 at 9:20:37 AM UTC-4, Tobias McNulty wrote:
>
> Agreed it's probably better to make the switch now, and I'd be fine 
> without a replacement shorthand alternative for --keepdb.
>
> Cheers,
>
>
> *Tobias McNulty*Chief Executive Officer
>
> tob...@caktusgroup.com 
> www.caktusgroup.com
>
>
> On Mon, Mar 11, 2019 at 8:19 AM Carlton Gibson  > wrote:
>
>> Thanks François,
>>
>> Just on this, my thought is that if we don't follow `unittest` in 
>> changing `-k` for this, we have a steady trickle of confusion forever-more. 
>> I'd rather avoid that. 
>>
>> C.
>>
>> On Monday, 11 March 2019 13:14:01 UTC+1, François Freitag wrote:
>>>
>>> Hi Django Devs, 
>>>
>>> https://code.djangoproject.com/ticket/30245 suggests supporting Python 
>>> unittest `-k` option, to selectively run tests matching a keyword. 
>>>
>>> Currently, `-k` is the shorthand for `--keepdb` in Django. 
>>> A `--filter` flag was suggested to preserve backward compatibility. 
>>> Carlton suggested removing the `-k` option from `--keepdb` and reusing 
>>> it for unittest `-k`. That would follow unittest more closely, reduce 
>>> user confusion and ease maintenance. 
>>>
>>> What do you think is best? Do you see other options? 
>>>
>>> If re-taking the `-k` option for unittest `-k`, should a new shorthand 
>>> be introduced for `--keepdb`? 
>>>
>>> Thanks for your time, 
>>> François 
>>>
>> -- 
>> 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/c54e52d2-012a-4852-9375-be37add55945%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/d0f1df05-238c-4ad6-97c2-a852bda939bc%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.


Fellow Reports - March 2019

2019-03-11 Thread Tim Graham


Week ending March 9, 2019

Triaged

---

https://code.djangoproject.com/ticket/30232 - Correct expected format in 
invalid DurationField error message (fixed)

https://code.djangoproject.com/ticket/30231 - Field's verbose_name is 
ignored in FilteredSelectMultiple widget for inlines created with "Add 
another" button (accepted)

https://code.djangoproject.com/ticket/30236 - UsernameField should use 
autocapitalize="none" (accepted)

Reviewed/committed

--

https://github.com/django/django/pull/10390 - Fixed #29754 -- Added is_dst 
parameter to Trunc database functions.

https://github.com/django/django/pull/11053 - Fixed #30234 -- Disallowed 
non-upper settings in settings.configure().

https://github.com/django/django/pull/11018 - Doc'd the use of --noinput 
for test database handling.

https://github.com/django/django/pull/11039 - Fixed #30189 -- Removed 
transaction from sqlmigrate output if database doesn't use one.
https://github.com/django/django/pull/10997 - Fixed #30186 -- Made 
showmigrations --list display the applied datetimes at verbosity 2+.

-- 
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/421fb768-f9b6-4a58-8f9b-daa22e5e8a30%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.


Re: Support for unittest -k option

2019-03-11 Thread Tobias McNulty
Agreed it's probably better to make the switch now, and I'd be fine without
a replacement shorthand alternative for --keepdb.

Cheers,


*Tobias McNulty*Chief Executive Officer

tob...@caktusgroup.com
www.caktusgroup.com


On Mon, Mar 11, 2019 at 8:19 AM Carlton Gibson 
wrote:

> Thanks François,
>
> Just on this, my thought is that if we don't follow `unittest` in changing
> `-k` for this, we have a steady trickle of confusion forever-more.
> I'd rather avoid that.
>
> C.
>
> On Monday, 11 March 2019 13:14:01 UTC+1, François Freitag wrote:
>>
>> Hi Django Devs,
>>
>> https://code.djangoproject.com/ticket/30245 suggests supporting Python
>> unittest `-k` option, to selectively run tests matching a keyword.
>>
>> Currently, `-k` is the shorthand for `--keepdb` in Django.
>> A `--filter` flag was suggested to preserve backward compatibility.
>> Carlton suggested removing the `-k` option from `--keepdb` and reusing
>> it for unittest `-k`. That would follow unittest more closely, reduce
>> user confusion and ease maintenance.
>>
>> What do you think is best? Do you see other options?
>>
>> If re-taking the `-k` option for unittest `-k`, should a new shorthand
>> be introduced for `--keepdb`?
>>
>> Thanks for your time,
>> François
>>
> --
> 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/c54e52d2-012a-4852-9375-be37add55945%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/CAMGFDKS1GCE3U824FZxMnzJTdZrq_9uuT60jiVHv%2BM4JR1%3D5%3DA%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.


Re: Support for unittest -k option

2019-03-11 Thread Adam Johnson
+1 from me, I'm okay with the small breaking change to keep in-line with
upstream unittest. Since it's restricted to tests, it's unlikely to break
anyone's production site.

On Mon, 11 Mar 2019 at 12:19, Carlton Gibson 
wrote:

> Thanks François,
>
> Just on this, my thought is that if we don't follow `unittest` in changing
> `-k` for this, we have a steady trickle of confusion forever-more.
> I'd rather avoid that.
>
> C.
>
> On Monday, 11 March 2019 13:14:01 UTC+1, François Freitag wrote:
>>
>> Hi Django Devs,
>>
>> https://code.djangoproject.com/ticket/30245 suggests supporting Python
>> unittest `-k` option, to selectively run tests matching a keyword.
>>
>> Currently, `-k` is the shorthand for `--keepdb` in Django.
>> A `--filter` flag was suggested to preserve backward compatibility.
>> Carlton suggested removing the `-k` option from `--keepdb` and reusing
>> it for unittest `-k`. That would follow unittest more closely, reduce
>> user confusion and ease maintenance.
>>
>> What do you think is best? Do you see other options?
>>
>> If re-taking the `-k` option for unittest `-k`, should a new shorthand
>> be introduced for `--keepdb`?
>>
>> Thanks for your time,
>> François
>>
> --
> 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/c54e52d2-012a-4852-9375-be37add55945%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/CAMyDDM3OdLXijQeNkckCoce-FptLbkpG7P%3Dy2F1KXU%2BnZhgb%2BA%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.


Re: Use CDN for djangoproject.com

2019-03-11 Thread Adam Johnson
Looking good! Thanks for your work Tobias.

I get 30ms through CDN instead of 230ms from here in London, UK.

I take back my bad comments about Fastly, since they are giving free
credits :) If you don't need custom Varnish code they are quite easy to
configure and easy to contact on IRC.n

On Mon, 11 Mar 2019 at 13:06, Tobias McNulty  wrote:

> Hi all,
>
> These changes have been deployed (though we're not yet using a CDN for the
> primary domain, docs.djangoproject.com, so you shouldn't notice a change).
>
> The alternate URL (https://django-docs.global.ssl.fastly.net/en/2.1/)
> will now cache docs pages for up to a week, and the hourly docs rebuilds
> will trigger a cache purge of (a) nothing if there have been no changes in
> the last hour, (b) just the dev docs if that's all that's changed or (c)
> the entire docs site if a release branch has changed. I've tested this a
> few times and everything seems to be working as it should, but please let
> me know if you see anything out of order.
>
> Currently we're waiting on the DSF/Fastly contract to be executed. Once
> that's done I think we'll be ready to move static.djangoproject.com and
> docs.djangoproject.com to Fastly.
>
> I did set up a CloudFront distribution for these domains as well, but
> given Fastly will give us the bandwidth for free we're having a hard time
> justifying using CloudFront instead. Of course, if anyone has a connection
> to $2000+ a year or so in AWS credits for the foreseeable future, let me
> know. :-)
>
> Finally, in preparation for the switch, I set up a status page (
> https://docs-status.djangoproject.com) that, at the time I wrote this
> email, at least, shows the following average response times to the docs
> site from around the world:
>
>- Mumbai: 1968 ms
>- Singapore: 1895 ms
>- Sydney: 2015 ms
>- Tokyo: 1490 ms
>- Canada (Central): 224 ms
>- Ireland: 705 ms
>- London: 525 ms
>- Sao Paulo: 911 ms
>- US East (N. Virginia): 149 ms
>- US West (Oregon): 721 ms
>
> You can click on an individual region to see the variability over time.
> I'm on the east coast in the US so I don't have a good way to confirm or
> deny most of these. They are HTTPS checks, and I believe the numbers
> represent the time to connect and retrieve the page content (for
> https://docs.djangoproject.com/en/2.1/).
>
> Cheers,
>
>
> *Tobias McNulty*Chief Executive Officer
>
> tob...@caktusgroup.com
> www.caktusgroup.com
>
>
> On Mon, Feb 25, 2019 at 10:56 AM Florian Apolloner 
> wrote:
>
>> Hi Tobias,
>>
>> I think a cache of something like a day will most certainly not hurt
>> anyone. If the need arises we can still manually purge the cache as needed.
>>
>> Cheers,
>> Florian
>>
>> On Sunday, February 24, 2019 at 1:00:50 AM UTC+1, Tobias McNulty wrote:
>>>
>>> Hi all,
>>>
>>> An implementation question has come up regarding cache lifetime (see this
>>> PR ). Right now,
>>> the whole site (including docs) has the site-wide Django cache enabled
>>> ,
>>> with a timeout of 5 minutes
>>> .
>>> A couple docs views (search_suggestions
>>> 
>>> and search_description
>>> )
>>> views have longer timeouts set (to 1 hour and 1 week, respectively).
>>>
>>> Once released, the vast majority of Django docs won't change much,
>>> except for the release notes section and any (likely minor) related updates
>>> to the docs themselves. To get the most benefit out of a CDN, it would
>>> obviously be desirable to set the timeout to something greater than 5
>>> minutes.
>>>
>>> At the same time, there are moments when a quick update to the docs *is*
>>> desired, and waiting an hour or more for any cached pages to expire may
>>> cause significant confusion, for example, in conjunction with a security
>>> release for which stubbed (non-final) release notes may have already been
>>> pushed out and cached.
>>>
>>> I see two main options at this point (which could even be combined):
>>>
>>> 1) Invalidate the whole cache (or at least some key release notes URLs)
>>> any time there's a docs build that has changes. It would be pretty easy to
>>> piggyback off of the existing business logic for avoiding a rebuild
>>> 
>>> if the git checkout hasn't changed (in the update_docs management command).
>>> 2) Pick subsections of the docs (e.g., for anything matching
>>> '///releases/*' and perhaps the development docs) that would
>>> keep a shorter cache timeout of 5-10 minutes. All URLs not specifically
>>> requiring this special treatment 

Re: Use CDN for djangoproject.com

2019-03-11 Thread Tobias McNulty
Hi all,

These changes have been deployed (though we're not yet using a CDN for the
primary domain, docs.djangoproject.com, so you shouldn't notice a change).

The alternate URL (https://django-docs.global.ssl.fastly.net/en/2.1/) will
now cache docs pages for up to a week, and the hourly docs rebuilds will
trigger a cache purge of (a) nothing if there have been no changes in the
last hour, (b) just the dev docs if that's all that's changed or (c) the
entire docs site if a release branch has changed. I've tested this a few
times and everything seems to be working as it should, but please let me
know if you see anything out of order.

Currently we're waiting on the DSF/Fastly contract to be executed. Once
that's done I think we'll be ready to move static.djangoproject.com and
docs.djangoproject.com to Fastly.

I did set up a CloudFront distribution for these domains as well, but given
Fastly will give us the bandwidth for free we're having a hard time
justifying using CloudFront instead. Of course, if anyone has a connection
to $2000+ a year or so in AWS credits for the foreseeable future, let me
know. :-)

Finally, in preparation for the switch, I set up a status page (
https://docs-status.djangoproject.com) that, at the time I wrote this
email, at least, shows the following average response times to the docs
site from around the world:

   - Mumbai: 1968 ms
   - Singapore: 1895 ms
   - Sydney: 2015 ms
   - Tokyo: 1490 ms
   - Canada (Central): 224 ms
   - Ireland: 705 ms
   - London: 525 ms
   - Sao Paulo: 911 ms
   - US East (N. Virginia): 149 ms
   - US West (Oregon): 721 ms

You can click on an individual region to see the variability over time. I'm
on the east coast in the US so I don't have a good way to confirm or deny
most of these. They are HTTPS checks, and I believe the numbers represent
the time to connect and retrieve the page content (for
https://docs.djangoproject.com/en/2.1/).

Cheers,


*Tobias McNulty*Chief Executive Officer

tob...@caktusgroup.com
www.caktusgroup.com


On Mon, Feb 25, 2019 at 10:56 AM Florian Apolloner 
wrote:

> Hi Tobias,
>
> I think a cache of something like a day will most certainly not hurt
> anyone. If the need arises we can still manually purge the cache as needed.
>
> Cheers,
> Florian
>
> On Sunday, February 24, 2019 at 1:00:50 AM UTC+1, Tobias McNulty wrote:
>>
>> Hi all,
>>
>> An implementation question has come up regarding cache lifetime (see this
>> PR ). Right now,
>> the whole site (including docs) has the site-wide Django cache enabled
>> ,
>> with a timeout of 5 minutes
>> .
>> A couple docs views (search_suggestions
>> 
>> and search_description
>> )
>> views have longer timeouts set (to 1 hour and 1 week, respectively).
>>
>> Once released, the vast majority of Django docs won't change much, except
>> for the release notes section and any (likely minor) related updates to the
>> docs themselves. To get the most benefit out of a CDN, it would obviously
>> be desirable to set the timeout to something greater than 5 minutes.
>>
>> At the same time, there are moments when a quick update to the docs *is*
>> desired, and waiting an hour or more for any cached pages to expire may
>> cause significant confusion, for example, in conjunction with a security
>> release for which stubbed (non-final) release notes may have already been
>> pushed out and cached.
>>
>> I see two main options at this point (which could even be combined):
>>
>> 1) Invalidate the whole cache (or at least some key release notes URLs)
>> any time there's a docs build that has changes. It would be pretty easy to
>> piggyback off of the existing business logic for avoiding a rebuild
>> 
>> if the git checkout hasn't changed (in the update_docs management command).
>> 2) Pick subsections of the docs (e.g., for anything matching
>> '///releases/*' and perhaps the development docs) that would
>> keep a shorter cache timeout of 5-10 minutes. All URLs not specifically
>> requiring this special treatment would get a longer timeout, perhaps
>> somewhere between 1 and 24 hours.
>>
>> So, some questions for the list:
>>
>> * Are there sections of the docs besides '///releases/'
>> and '//dev/' that might update frequently and merit some combination
>> of invalidation and/or a shorter cache time? And what's a good cache
>> timeout for such pages?
>> * How long are we comfortable waiting for *other* (not frequently
>> updated) pages to timeout, in the event they do change?
>>
>> Tobias
>>
>> On Fri, 

Re: Support for unittest -k option

2019-03-11 Thread Carlton Gibson
Thanks François,

Just on this, my thought is that if we don't follow `unittest` in changing 
`-k` for this, we have a steady trickle of confusion forever-more. 
I'd rather avoid that. 

C.

On Monday, 11 March 2019 13:14:01 UTC+1, François Freitag wrote:
>
> Hi Django Devs, 
>
> https://code.djangoproject.com/ticket/30245 suggests supporting Python 
> unittest `-k` option, to selectively run tests matching a keyword. 
>
> Currently, `-k` is the shorthand for `--keepdb` in Django. 
> A `--filter` flag was suggested to preserve backward compatibility. 
> Carlton suggested removing the `-k` option from `--keepdb` and reusing 
> it for unittest `-k`. That would follow unittest more closely, reduce 
> user confusion and ease maintenance. 
>
> What do you think is best? Do you see other options? 
>
> If re-taking the `-k` option for unittest `-k`, should a new shorthand 
> be introduced for `--keepdb`? 
>
> Thanks for your time, 
> François 
>

-- 
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/c54e52d2-012a-4852-9375-be37add55945%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.


Support for unittest -k option

2019-03-11 Thread François Freitag
Hi Django Devs,

https://code.djangoproject.com/ticket/30245 suggests supporting Python
unittest `-k` option, to selectively run tests matching a keyword.

Currently, `-k` is the shorthand for `--keepdb` in Django.
A `--filter` flag was suggested to preserve backward compatibility.
Carlton suggested removing the `-k` option from `--keepdb` and reusing
it for unittest `-k`. That would follow unittest more closely, reduce
user confusion and ease maintenance.

What do you think is best? Do you see other options?

If re-taking the `-k` option for unittest `-k`, should a new shorthand
be introduced for `--keepdb`?

Thanks for your time,
François

-- 
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/f17da2c4-b311-75ca-8a52-33504391eb0c%40gmail.com.
For more options, visit https://groups.google.com/d/optout.