Re: Use CDN for djangoproject.com

[Cheng C]

Thanks for the test site, Tobias. 

Tested from Melbourne, Australia: 

https://docs.djangoproject.com/en/2.1/
Average Ping: 268ms
 Browser: 22 requests, 238KB transferred, Finish: 2.72s, DOMContentLoaded: 
1.37s, Load: 1.68s

https://docs.djangoproject.com.global.prod.fastly.net/en/2.1/
Average Ping: 28ms
 Browser: 22 requests, 240KB transferred, Finish: 947ms, DOMContentLoaded: 
627ms, Load: 910ms

Tested on Chrome with "Disable cache" checked, and no render issue was 
found.

On Friday, February 15, 2019 at 2:09:09 PM UTC+11, Tobias McNulty wrote:
>
> Adam, is there another provider you would recommend instead, that does not 
> require changing DNS providers? FWIW, python.org does in fact use Fastly:
>
> $ host www.python.org
> www.python.org is an alias for dualstack.python.map.fastly.net.
> dualstack.python.map.fastly.net has address 151.101.248.223
> dualstack.python.map.fastly.net has IPv6 address 2a04:4e42:2f::223
>
> Fastly did write back to say they're happy to help, though there's a 
> contract which I guess the DSF would need to review and sign, if it's 
> acceptable.
>
> In the meantime, feel free to give this a try and let me know if you see 
> any issues: https://docs.djangoproject.com.global.prod.fastly.net/en/2.1/ 
> (Not for permanent use, obviously; you'll get a cert warning, and some 
> pages will redirect you back to https://docs.djangoproject.com.)
>
> To keep this thread from getting too noisy, you can find me (tobias1) in 
> #django-dev on FreeNode.
>
> Cheers,
> Tobias
>
> On Thu, Feb 14, 2019 at 8:26 AM Adam Johnson > 
> wrote:
>
>> I have not had great experience with Fastly in the past and would avoid 
>> them. They run an old fork of Varnish which is not fun to configure.
>>
>> On Thu, 14 Feb 2019 at 11:16, Josh Smeaton > > wrote:
>>
>>> Cloudflare have many SSL options, including fully encrypted and 
>>> authenticated comms all the way through (terminate and reconnect). 
>>> Typically done by having a “hidden” origin domain that also hosts a 
>>> certificate. I’m unsure if it’s possible to have both origin and front 
>>> hosting the same name so that DNS alone can decide to hit cdn or origin. 
>>>
>>> Anyway, it seems weird to me to dismiss a CDN offhand “because 
>>> security”. Especially considering the size of the providers and the 
>>> expertise their teams have. 
>>>
>>> Cloudflare (fastly, cloudfront, whatever) aren’t some “random TLS” 
>>> providers. I would probably go as far to say that putting a CDN in front of 
>>> both the docs and the release packages would likely be a net improvement in 
>>> security for users. 
>>>
>>> On Thu, 14 Feb 2019 at 21:58, Tom Forbes > 
>>> wrote:
>>>
 That makes sense, but in this case we are only talking about 
 potentially yielding control of the docs subdomain which is not used to 
 serve sensitive build artefacts?

 Another option is fastly.com, who support other large open source 
 projects for free. They essentially give you geographically distributed 
 HAProxy instances and you have a lot more control over them. I believe 
 several large Linux distributions use them to serve cached apt packages.

 Regarding TLS termination, unfortunately any CDN we use will likely 
 need to do this for the whole domain to get any benefit. The Django docs 
 are text/html heavy with very few, if any, images. So the real speed 
 benefit will have to come from serving that, which requires TLS 
 termination 
 (and therefore interception) at their end.

 On Thu, 14 Feb 2019, 06:32 Markus Holtermann, <
 in...@markusholtermann.eu > wrote:

> Hi all
>
> to elaborate on what Tobias said: we deliberately have the 
> infrastructure spread across multiple service providers: DNS registry, 
> nameservers, hosting, TLS certificate authority, … None of them have 
> access 
> to everything. The reason is that we offer the download of the release 
> artifacts from the djangoproject.com website. And we would like to 
> ensure that the TLS termination happens by us and not some random service 
> provider. After all, Django is used by enterprises that do have some 
> restrictions on where you're allowed to download software from.
>
> By handing over DNS to some CDN provider, we loose the ability to 
> ensure that happens.
>
> That said, if there's a CDN that works as a reverse proxy and doesn't 
> require us to hand over control of DNS, I guess we could be interested in 
> moving the docs behind that.
>
> /Markus
>
> On Thu, Feb 14, 2019, at 2:22 AM, Tobias McNulty wrote:
> > For me it's the trust factor (allowing someone else to decrypt and 
> > re-encrypt all our data). This may be less of an issue for the docs 
> > site, *if* we don't have to assign DNS authority for the whole 
> domain 
> > to the CDN provider.
> > 
> > Tobias
> > 
> > 
> > On Wed, Feb 13, 2019, 

Re: Use CDN for djangoproject.com

[Tobias McNulty]

Adam, is there another provider you would recommend instead, that does not
require changing DNS providers? FWIW, python.org does in fact use Fastly:

$ host www.python.org
www.python.org is an alias for dualstack.python.map.fastly.net.
dualstack.python.map.fastly.net has address 151.101.248.223
dualstack.python.map.fastly.net has IPv6 address 2a04:4e42:2f::223

Fastly did write back to say they're happy to help, though there's a
contract which I guess the DSF would need to review and sign, if it's
acceptable.

In the meantime, feel free to give this a try and let me know if you see
any issues: https://docs.djangoproject.com.global.prod.fastly.net/en/2.1/
(Not for permanent use, obviously; you'll get a cert warning, and some
pages will redirect you back to https://docs.djangoproject.com.)

To keep this thread from getting too noisy, you can find me (tobias1) in
#django-dev on FreeNode.

Cheers,
Tobias

On Thu, Feb 14, 2019 at 8:26 AM Adam Johnson  wrote:

> I have not had great experience with Fastly in the past and would avoid
> them. They run an old fork of Varnish which is not fun to configure.
>
> On Thu, 14 Feb 2019 at 11:16, Josh Smeaton  wrote:
>
>> Cloudflare have many SSL options, including fully encrypted and
>> authenticated comms all the way through (terminate and reconnect).
>> Typically done by having a “hidden” origin domain that also hosts a
>> certificate. I’m unsure if it’s possible to have both origin and front
>> hosting the same name so that DNS alone can decide to hit cdn or origin.
>>
>> Anyway, it seems weird to me to dismiss a CDN offhand “because security”.
>> Especially considering the size of the providers and the expertise their
>> teams have.
>>
>> Cloudflare (fastly, cloudfront, whatever) aren’t some “random TLS”
>> providers. I would probably go as far to say that putting a CDN in front of
>> both the docs and the release packages would likely be a net improvement in
>> security for users.
>>
>> On Thu, 14 Feb 2019 at 21:58, Tom Forbes  wrote:
>>
>>> That makes sense, but in this case we are only talking about potentially
>>> yielding control of the docs subdomain which is not used to serve sensitive
>>> build artefacts?
>>>
>>> Another option is fastly.com, who support other large open source
>>> projects for free. They essentially give you geographically distributed
>>> HAProxy instances and you have a lot more control over them. I believe
>>> several large Linux distributions use them to serve cached apt packages.
>>>
>>> Regarding TLS termination, unfortunately any CDN we use will likely need
>>> to do this for the whole domain to get any benefit. The Django docs are
>>> text/html heavy with very few, if any, images. So the real speed benefit
>>> will have to come from serving that, which requires TLS termination (and
>>> therefore interception) at their end.
>>>
>>> On Thu, 14 Feb 2019, 06:32 Markus Holtermann, 
>>> wrote:
>>>
 Hi all

 to elaborate on what Tobias said: we deliberately have the
 infrastructure spread across multiple service providers: DNS registry,
 nameservers, hosting, TLS certificate authority, … None of them have access
 to everything. The reason is that we offer the download of the release
 artifacts from the djangoproject.com website. And we would like to
 ensure that the TLS termination happens by us and not some random service
 provider. After all, Django is used by enterprises that do have some
 restrictions on where you're allowed to download software from.

 By handing over DNS to some CDN provider, we loose the ability to
 ensure that happens.

 That said, if there's a CDN that works as a reverse proxy and doesn't
 require us to hand over control of DNS, I guess we could be interested in
 moving the docs behind that.

 /Markus

 On Thu, Feb 14, 2019, at 2:22 AM, Tobias McNulty wrote:
 > For me it's the trust factor (allowing someone else to decrypt and
 > re-encrypt all our data). This may be less of an issue for the docs
 > site, *if* we don't have to assign DNS authority for the whole domain
 > to the CDN provider.
 >
 > Tobias
 >
 >
 > On Wed, Feb 13, 2019, 7:47 PM Kye Russell >>> > > I’ve been hearing that there are other CDN providers that offer a
 very comparable service for a fraction of the cost of CloudFront.
 > >
 > > Anyways, at this stage let’s not get bogged down on provider
 decisions. I’m curious if anyone has any general objections to a CDN of any
 kind.
 > >
 > > It shouldn’t be that big a deal to automatically invalidate when
 the docs are updated. But I’m sure there’s something I’m missing.
 > >
 > > On Thu, 14 Feb 2019 at 8:36 am, Cristiano Coelho <
 cristianocc...@gmail.com> wrote:
 > >> Consider AWS's cloudfront then :)
 > >>
 > >> El martes, 12 de febrero de 2019, 2:34:09 (UTC-5), Florian
 Apolloner escribió:
 > >>> Especially cloudflare 

Re: Upload images in admin panel

[Adam Johnson]

This mailing list is for the development. of Django itself, not for support
using Django. Please use the django-users mailing list for that, or IRC
#django on freenode, or a site like Stack Overflow.

On Thu, 14 Feb 2019 at 19:29, Surajeet Das  wrote:

> How do I upload images in the admin panel ?
>
> --
> 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/5f7bec22-6526-4c45-8882-fc040a5df178%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/CAMyDDM3_axmcv-F9xt-G3nzA80x_AQ53L6SeYg5aO3YUhkhFvw%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: Automating the process of creating models from the data file provided

[Abhilasha Jha]

Hi Collin
Thanks for the reply. I will see what I can do, and if this project is worth 
pursuing.

Best regards
Abhilasha

-- 
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/3ea14e48-6292-40cd-8dee-d03199e25fff%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: Automating the process of creating models from the data file provided

[Abhilasha Jha]

Hi Carlton,
Thanks for the reply, saw it today. Will go through the links you have given.

Best regards
Abhilasha

-- 
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/80c22971-9171-4231-a8a3-6fa52aac520a%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: Google Summer of Code 2019

[vineeth sagar]

One good thing we can add is redis support for caching, it's good that
there are libraries out there, it's about time redis is included, because
it's well documented and does all the things memcached does and even more.

Or maybe some async support.

regards
Vineeth

On Thu, 14 Feb, 2019, 23:30 Tom Forbes  Out of interest, do the projects for GSOC have to fall within the Django
> repository themselves? Could they be an associated project under the Django
> umbrella?
>
> I think something that helps with deployment in general could be
> interesting, but it definitely does not live inside Django core. However
> some form of 3rd party package exploring this is another matter entirely.
>
> On 14 February 2019 at 17:56:04, Carlton Gibson (carlton.gib...@gmail.com)
> wrote:
>
> Hmmm. I think that would be out for scope for Django. More suited to tools
> such as Ansible (and similar). I don't think adding a one step deployment
> story would really be feasible within a GSoC project. (As you say, it's
> very complex.)
>
> On Thursday, 14 February 2019 18:46:52 UTC+1, Shashank shet wrote:
>>
>> Thank you Carlton. I had in mind an idea for providing out-of-the-box
>> webserver deployment capability. In the projects I've done, one of the most
>> time consuming tasks for us was deployment on a server, mainly due to a
>> lack of experience. That's why I figured that an automated system for
>> deployment would be helpful. It would work similar to the runserver
>> command, taking essential configurations from a designated file and not
>> having to actually make changes to files in different parts of the
>> filesystem, or following a long list of instructions manually. Any
>> suggestion would be very helpful.
>>
>>
>> On Thursday, February 14, 2019 at 6:32:17 PM UTC+5:30, Carlton Gibson
>> wrote:
>>>
>>> Hi Shashank.
>>>
>>> "Sir"? That's my father, surely.  (Not "sir" )
>>>
>>> We've applied as an Org. Haven't heard yet whether we'll be accepted.
>>>
>>> If so, proposals would be welcome. We'd then need to think about
>>> mentors. Good proposals will draw out people there.
>>>
>>> If we can get all that lined up then, yes, in principle we're accepting
>>> applications.
>>>
>>> Kind Regards,
>>>
>>> Carlton
>>>
>>>
>>> On Thursday, 14 February 2019 13:46:57 UTC+1, Shashank shet wrote:

 Hello Carlton sir,
 I have worked on Django as a part of a project and wished to ask if the
 organization is still accepting proposals for GSoC 2019.

 On Monday, February 4, 2019 at 8:25:42 PM UTC+5:30, Carlton Gibson
 wrote:
>
> And thank you Tim, yes, exactly what I need.
>
> To all:
>
> I will put in the org application today. We'll then see about the
> proposals.
>
> The main thing is that we need to know who you are, and have
> confidence in you in order to commit to the project with you.
> For people to mentor you is a big commitment of time and energy. You
> need to demonstrate that will be well invested.
>
> The way to do that is to get involved and show us who you are over the
> next few months.
> Help reproduce bugs, review patches, create patches etc.
> It doesn't take much before you're visible. (Really!)
>
> The best way (also) to come up with project ideas is to see where
> there are issues already.
> (Much better than us providing a list.) So again, be involved.
>
> If you start now, there's still lots of time, so I'm hoping.
>
> Kind Regards,
>
> Carlton
>
>
>
>
>
> On Monday, 4 February 2019 15:43:39 UTC+1, Tim Graham wrote:
>>
>> It's a private wiki that only Django team members like Carlton can
>> access. It contains the information for Django to apply for GSoC.
>>
>> On Monday, February 4, 2019 at 9:07:40 AM UTC-5, Giuseppe De Marco
>> wrote:
>>>
>>> Hi Tim,
>>>
>>> It returns 404 to me
>>>
>>> https://github.com/django/django-team-wiki/wiki/Google-Summer-of-Code-Application-Info
>>>
>>> Il giorno lun 4 feb 2019 alle ore 13:05 Tim Graham <
>>> timog...@gmail.com> ha scritto:
>>>
 All answers are at
 https://github.com/django/django-team-wiki/wiki/Google-Summer-of-Code-Application-Info

>>> --
> 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/87bb632d-360c-486d-92e1-431ddcb05bb2%40googlegroups.com
> 

Re: Google Summer of Code 2019

[kamalesh palanisamy]

I have also been working on Django for two projects when will the 
applications be available Sir?

On Thursday, February 14, 2019 at 6:32:17 PM UTC+5:30, Carlton Gibson wrote:
>
> Hi Shashank. 
>
> "Sir"? That's my father, surely.  (Not "sir" ) 
>
> We've applied as an Org. Haven't heard yet whether we'll be accepted. 
>
> If so, proposals would be welcome. We'd then need to think about mentors. 
> Good proposals will draw out people there. 
>
> If we can get all that lined up then, yes, in principle we're accepting 
> applications. 
>
> Kind Regards,
>
> Carlton
>
>
> On Thursday, 14 February 2019 13:46:57 UTC+1, Shashank shet wrote:
>>
>> Hello Carlton sir,
>> I have worked on Django as a part of a project and wished to ask if the 
>> organization is still accepting proposals for GSoC 2019. 
>>
>> On Monday, February 4, 2019 at 8:25:42 PM UTC+5:30, Carlton Gibson wrote:
>>>
>>> And thank you Tim, yes, exactly what I need. 
>>>
>>> To all: 
>>>
>>> I will put in the org application today. We'll then see about the 
>>> proposals. 
>>>
>>> The main thing is that we need to know who you are, and have confidence 
>>> in you in order to commit to the project with you. 
>>> For people to mentor you is a big commitment of time and energy. You 
>>> need to demonstrate that will be well invested. 
>>>
>>> The way to do that is to get involved and show us who you are over the 
>>> next few months. 
>>> Help reproduce bugs, review patches, create patches etc. 
>>> It doesn't take much before you're visible. (Really!) 
>>>
>>> The best way (also) to come up with project ideas is to see where there 
>>> are issues already. 
>>> (Much better than us providing a list.) So again, be involved. 
>>>
>>> If you start now, there's still lots of time, so I'm hoping. 
>>>
>>> Kind Regards,
>>>
>>> Carlton
>>>
>>>
>>>
>>>
>>>
>>> On Monday, 4 February 2019 15:43:39 UTC+1, Tim Graham wrote:

 It's a private wiki that only Django team members like Carlton can 
 access. It contains the information for Django to apply for GSoC.

 On Monday, February 4, 2019 at 9:07:40 AM UTC-5, Giuseppe De Marco 
 wrote:
>
> Hi Tim,
>
> It returns 404 to me
>
> https://github.com/django/django-team-wiki/wiki/Google-Summer-of-Code-Application-Info
>
> Il giorno lun 4 feb 2019 alle ore 13:05 Tim Graham  
> ha scritto:
>
>> All answers are at 
>> https://github.com/django/django-team-wiki/wiki/Google-Summer-of-Code-Application-Info
>>
>

-- 
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/33db7ed5-8786-429b-a342-03dd4a84f7ed%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Upload images in admin panel

[Surajeet Das]

How do I upload images in the admin panel ?

-- 
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/5f7bec22-6526-4c45-8882-fc040a5df178%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: Google Summer of Code 2019

[Shashank shet]

That seems accurate.
In your opinion, would it still be infeasible to provide support for one 
stack to begin with? For example: gunicorn + nginx? And that can ultimately 
lead to support for other configurations.

On Thursday, February 14, 2019 at 11:25:57 PM UTC+5:30, Carlton Gibson 
wrote:
>
> Hmmm. I think that would be out for scope for Django. More suited to tools 
> such as Ansible (and similar). I don't think adding a one step deployment 
> story would really be feasible within a GSoC project. (As you say, it's 
> very complex.) 
>
> On Thursday, 14 February 2019 18:46:52 UTC+1, Shashank shet wrote:
>>
>> Thank you Carlton. I had in mind an idea for providing out-of-the-box 
>> webserver deployment capability. In the projects I've done, one of the most 
>> time consuming tasks for us was deployment on a server, mainly due to a 
>> lack of experience. That's why I figured that an automated system for 
>> deployment would be helpful. It would work similar to the runserver 
>> command, taking essential configurations from a designated file and not 
>> having to actually make changes to files in different parts of the 
>> filesystem, or following a long list of instructions manually. Any 
>> suggestion would be very helpful.
>>
>>
>> On Thursday, February 14, 2019 at 6:32:17 PM UTC+5:30, Carlton Gibson 
>> wrote:
>>>
>>> Hi Shashank. 
>>>
>>> "Sir"? That's my father, surely.  (Not "sir" ) 
>>>
>>> We've applied as an Org. Haven't heard yet whether we'll be accepted. 
>>>
>>> If so, proposals would be welcome. We'd then need to think about 
>>> mentors. Good proposals will draw out people there. 
>>>
>>> If we can get all that lined up then, yes, in principle we're accepting 
>>> applications. 
>>>
>>> Kind Regards,
>>>
>>> Carlton
>>>
>>>
>>> On Thursday, 14 February 2019 13:46:57 UTC+1, Shashank shet wrote:

 Hello Carlton sir,
 I have worked on Django as a part of a project and wished to ask if the 
 organization is still accepting proposals for GSoC 2019. 

 On Monday, February 4, 2019 at 8:25:42 PM UTC+5:30, Carlton Gibson 
 wrote:
>
> And thank you Tim, yes, exactly what I need. 
>
> To all: 
>
> I will put in the org application today. We'll then see about the 
> proposals. 
>
> The main thing is that we need to know who you are, and have 
> confidence in you in order to commit to the project with you. 
> For people to mentor you is a big commitment of time and energy. You 
> need to demonstrate that will be well invested. 
>
> The way to do that is to get involved and show us who you are over the 
> next few months. 
> Help reproduce bugs, review patches, create patches etc. 
> It doesn't take much before you're visible. (Really!) 
>
> The best way (also) to come up with project ideas is to see where 
> there are issues already. 
> (Much better than us providing a list.) So again, be involved. 
>
> If you start now, there's still lots of time, so I'm hoping. 
>
> Kind Regards,
>
> Carlton
>
>
>
>
>
> On Monday, 4 February 2019 15:43:39 UTC+1, Tim Graham wrote:
>>
>> It's a private wiki that only Django team members like Carlton can 
>> access. It contains the information for Django to apply for GSoC.
>>
>> On Monday, February 4, 2019 at 9:07:40 AM UTC-5, Giuseppe De Marco 
>> wrote:
>>>
>>> Hi Tim,
>>>
>>> It returns 404 to me
>>>
>>> https://github.com/django/django-team-wiki/wiki/Google-Summer-of-Code-Application-Info
>>>
>>> Il giorno lun 4 feb 2019 alle ore 13:05 Tim Graham <
>>> timog...@gmail.com> ha scritto:
>>>
 All answers are at 
 https://github.com/django/django-team-wiki/wiki/Google-Summer-of-Code-Application-Info

>>>

-- 
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/3524c6a5-0b6f-4fae-ad92-c007b51cc4cb%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: Google Summer of Code 2019

[Tom Forbes]

Out of interest, do the projects for GSOC have to fall within the Django 
repository themselves? Could they be an associated project under the Django 
umbrella?

I think something that helps with deployment in general could be interesting, 
but it definitely does not live inside Django core. However some form of 3rd 
party package exploring this is another matter entirely.

On 14 February 2019 at 17:56:04, Carlton Gibson (carlton.gib...@gmail.com) 
wrote:

Hmmm. I think that would be out for scope for Django. More suited to tools such 
as Ansible (and similar). I don't think adding a one step deployment story 
would really be feasible within a GSoC project. (As you say, it's very 
complex.) 

On Thursday, 14 February 2019 18:46:52 UTC+1, Shashank shet wrote:
Thank you Carlton. I had in mind an idea for providing out-of-the-box webserver 
deployment capability. In the projects I've done, one of the most time 
consuming tasks for us was deployment on a server, mainly due to a lack of 
experience. That's why I figured that an automated system for deployment would 
be helpful. It would work similar to the runserver command, taking essential 
configurations from a designated file and not having to actually make changes 
to files in different parts of the filesystem, or following a long list of 
instructions manually. Any suggestion would be very helpful.


On Thursday, February 14, 2019 at 6:32:17 PM UTC+5:30, Carlton Gibson wrote:
Hi Shashank. 

"Sir"? That's my father, surely.  (Not "sir" ) 

We've applied as an Org. Haven't heard yet whether we'll be accepted. 

If so, proposals would be welcome. We'd then need to think about mentors. Good 
proposals will draw out people there. 

If we can get all that lined up then, yes, in principle we're accepting 
applications. 

Kind Regards,

Carlton


On Thursday, 14 February 2019 13:46:57 UTC+1, Shashank shet wrote:
Hello Carlton sir,
I have worked on Django as a part of a project and wished to ask if the 
organization is still accepting proposals for GSoC 2019.

On Monday, February 4, 2019 at 8:25:42 PM UTC+5:30, Carlton Gibson wrote:
And thank you Tim, yes, exactly what I need. 

To all: 

I will put in the org application today. We'll then see about the proposals. 

The main thing is that we need to know who you are, and have confidence in you 
in order to commit to the project with you. 
For people to mentor you is a big commitment of time and energy. You need to 
demonstrate that will be well invested. 

The way to do that is to get involved and show us who you are over the next few 
months. 
Help reproduce bugs, review patches, create patches etc. 
It doesn't take much before you're visible. (Really!) 

The best way (also) to come up with project ideas is to see where there are 
issues already. 
(Much better than us providing a list.) So again, be involved. 

If you start now, there's still lots of time, so I'm hoping. 

Kind Regards,

Carlton





On Monday, 4 February 2019 15:43:39 UTC+1, Tim Graham wrote:
It's a private wiki that only Django team members like Carlton can access. It 
contains the information for Django to apply for GSoC.

On Monday, February 4, 2019 at 9:07:40 AM UTC-5, Giuseppe De Marco wrote:
Hi Tim,

It returns 404 to me
https://github.com/django/django-team-wiki/wiki/Google-Summer-of-Code-Application-Info

Il giorno lun 4 feb 2019 alle ore 13:05 Tim Graham  ha 
scritto:
All answers are at 
https://github.com/django/django-team-wiki/wiki/Google-Summer-of-Code-Application-Info
--
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/87bb632d-360c-486d-92e1-431ddcb05bb2%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/etPan.5c65ac70.3059ef5e.2b4%40tomforb.es.
For more options, visit https://groups.google.com/d/optout.

Re: Google Summer of Code 2019

[Carlton Gibson]

Hmmm. I think that would be out for scope for Django. More suited to tools 
such as Ansible (and similar). I don't think adding a one step deployment 
story would really be feasible within a GSoC project. (As you say, it's 
very complex.) 

On Thursday, 14 February 2019 18:46:52 UTC+1, Shashank shet wrote:
>
> Thank you Carlton. I had in mind an idea for providing out-of-the-box 
> webserver deployment capability. In the projects I've done, one of the most 
> time consuming tasks for us was deployment on a server, mainly due to a 
> lack of experience. That's why I figured that an automated system for 
> deployment would be helpful. It would work similar to the runserver 
> command, taking essential configurations from a designated file and not 
> having to actually make changes to files in different parts of the 
> filesystem, or following a long list of instructions manually. Any 
> suggestion would be very helpful.
>
>
> On Thursday, February 14, 2019 at 6:32:17 PM UTC+5:30, Carlton Gibson 
> wrote:
>>
>> Hi Shashank. 
>>
>> "Sir"? That's my father, surely.  (Not "sir" ) 
>>
>> We've applied as an Org. Haven't heard yet whether we'll be accepted. 
>>
>> If so, proposals would be welcome. We'd then need to think about mentors. 
>> Good proposals will draw out people there. 
>>
>> If we can get all that lined up then, yes, in principle we're accepting 
>> applications. 
>>
>> Kind Regards,
>>
>> Carlton
>>
>>
>> On Thursday, 14 February 2019 13:46:57 UTC+1, Shashank shet wrote:
>>>
>>> Hello Carlton sir,
>>> I have worked on Django as a part of a project and wished to ask if the 
>>> organization is still accepting proposals for GSoC 2019. 
>>>
>>> On Monday, February 4, 2019 at 8:25:42 PM UTC+5:30, Carlton Gibson wrote:

 And thank you Tim, yes, exactly what I need. 

 To all: 

 I will put in the org application today. We'll then see about the 
 proposals. 

 The main thing is that we need to know who you are, and have confidence 
 in you in order to commit to the project with you. 
 For people to mentor you is a big commitment of time and energy. You 
 need to demonstrate that will be well invested. 

 The way to do that is to get involved and show us who you are over the 
 next few months. 
 Help reproduce bugs, review patches, create patches etc. 
 It doesn't take much before you're visible. (Really!) 

 The best way (also) to come up with project ideas is to see where there 
 are issues already. 
 (Much better than us providing a list.) So again, be involved. 

 If you start now, there's still lots of time, so I'm hoping. 

 Kind Regards,

 Carlton





 On Monday, 4 February 2019 15:43:39 UTC+1, Tim Graham wrote:
>
> It's a private wiki that only Django team members like Carlton can 
> access. It contains the information for Django to apply for GSoC.
>
> On Monday, February 4, 2019 at 9:07:40 AM UTC-5, Giuseppe De Marco 
> wrote:
>>
>> Hi Tim,
>>
>> It returns 404 to me
>>
>> https://github.com/django/django-team-wiki/wiki/Google-Summer-of-Code-Application-Info
>>
>> Il giorno lun 4 feb 2019 alle ore 13:05 Tim Graham <
>> timog...@gmail.com> ha scritto:
>>
>>> All answers are at 
>>> https://github.com/django/django-team-wiki/wiki/Google-Summer-of-Code-Application-Info
>>>
>>

-- 
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/87bb632d-360c-486d-92e1-431ddcb05bb2%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: Google Summer of Code 2019

[Shashank shet]

Thank you Carlton. I had in mind an idea for providing out-of-the-box 
webserver deployment capability. In the projects I've done, one of the most 
time consuming tasks for us was deployment on a server, mainly due to a 
lack of experience. That's why I figured that an automated system for 
deployment would be helpful. It would work similar to the runserver 
command, taking essential configurations from a designated file and not 
having to actually make changes to files in different parts of the 
filesystem, or following a long list of instructions manually. Any 
suggestion would be very helpful.


On Thursday, February 14, 2019 at 6:32:17 PM UTC+5:30, Carlton Gibson wrote:
>
> Hi Shashank. 
>
> "Sir"? That's my father, surely.  (Not "sir" ) 
>
> We've applied as an Org. Haven't heard yet whether we'll be accepted. 
>
> If so, proposals would be welcome. We'd then need to think about mentors. 
> Good proposals will draw out people there. 
>
> If we can get all that lined up then, yes, in principle we're accepting 
> applications. 
>
> Kind Regards,
>
> Carlton
>
>
> On Thursday, 14 February 2019 13:46:57 UTC+1, Shashank shet wrote:
>>
>> Hello Carlton sir,
>> I have worked on Django as a part of a project and wished to ask if the 
>> organization is still accepting proposals for GSoC 2019. 
>>
>> On Monday, February 4, 2019 at 8:25:42 PM UTC+5:30, Carlton Gibson wrote:
>>>
>>> And thank you Tim, yes, exactly what I need. 
>>>
>>> To all: 
>>>
>>> I will put in the org application today. We'll then see about the 
>>> proposals. 
>>>
>>> The main thing is that we need to know who you are, and have confidence 
>>> in you in order to commit to the project with you. 
>>> For people to mentor you is a big commitment of time and energy. You 
>>> need to demonstrate that will be well invested. 
>>>
>>> The way to do that is to get involved and show us who you are over the 
>>> next few months. 
>>> Help reproduce bugs, review patches, create patches etc. 
>>> It doesn't take much before you're visible. (Really!) 
>>>
>>> The best way (also) to come up with project ideas is to see where there 
>>> are issues already. 
>>> (Much better than us providing a list.) So again, be involved. 
>>>
>>> If you start now, there's still lots of time, so I'm hoping. 
>>>
>>> Kind Regards,
>>>
>>> Carlton
>>>
>>>
>>>
>>>
>>>
>>> On Monday, 4 February 2019 15:43:39 UTC+1, Tim Graham wrote:

 It's a private wiki that only Django team members like Carlton can 
 access. It contains the information for Django to apply for GSoC.

 On Monday, February 4, 2019 at 9:07:40 AM UTC-5, Giuseppe De Marco 
 wrote:
>
> Hi Tim,
>
> It returns 404 to me
>
> https://github.com/django/django-team-wiki/wiki/Google-Summer-of-Code-Application-Info
>
> Il giorno lun 4 feb 2019 alle ore 13:05 Tim Graham  
> ha scritto:
>
>> All answers are at 
>> https://github.com/django/django-team-wiki/wiki/Google-Summer-of-Code-Application-Info
>>
>

-- 
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/768cd93b-5910-4f1c-84ed-cdfc6bf27da1%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: Use CDN for djangoproject.com

[Adam Johnson]

I have not had great experience with Fastly in the past and would avoid
them. They run an old fork of Varnish which is not fun to configure.

On Thu, 14 Feb 2019 at 11:16, Josh Smeaton  wrote:

> Cloudflare have many SSL options, including fully encrypted and
> authenticated comms all the way through (terminate and reconnect).
> Typically done by having a “hidden” origin domain that also hosts a
> certificate. I’m unsure if it’s possible to have both origin and front
> hosting the same name so that DNS alone can decide to hit cdn or origin.
>
> Anyway, it seems weird to me to dismiss a CDN offhand “because security”.
> Especially considering the size of the providers and the expertise their
> teams have.
>
> Cloudflare (fastly, cloudfront, whatever) aren’t some “random TLS”
> providers. I would probably go as far to say that putting a CDN in front of
> both the docs and the release packages would likely be a net improvement in
> security for users.
>
> On Thu, 14 Feb 2019 at 21:58, Tom Forbes  wrote:
>
>> That makes sense, but in this case we are only talking about potentially
>> yielding control of the docs subdomain which is not used to serve sensitive
>> build artefacts?
>>
>> Another option is fastly.com, who support other large open source
>> projects for free. They essentially give you geographically distributed
>> HAProxy instances and you have a lot more control over them. I believe
>> several large Linux distributions use them to serve cached apt packages.
>>
>> Regarding TLS termination, unfortunately any CDN we use will likely need
>> to do this for the whole domain to get any benefit. The Django docs are
>> text/html heavy with very few, if any, images. So the real speed benefit
>> will have to come from serving that, which requires TLS termination (and
>> therefore interception) at their end.
>>
>> On Thu, 14 Feb 2019, 06:32 Markus Holtermann, 
>> wrote:
>>
>>> Hi all
>>>
>>> to elaborate on what Tobias said: we deliberately have the
>>> infrastructure spread across multiple service providers: DNS registry,
>>> nameservers, hosting, TLS certificate authority, … None of them have access
>>> to everything. The reason is that we offer the download of the release
>>> artifacts from the djangoproject.com website. And we would like to
>>> ensure that the TLS termination happens by us and not some random service
>>> provider. After all, Django is used by enterprises that do have some
>>> restrictions on where you're allowed to download software from.
>>>
>>> By handing over DNS to some CDN provider, we loose the ability to ensure
>>> that happens.
>>>
>>> That said, if there's a CDN that works as a reverse proxy and doesn't
>>> require us to hand over control of DNS, I guess we could be interested in
>>> moving the docs behind that.
>>>
>>> /Markus
>>>
>>> On Thu, Feb 14, 2019, at 2:22 AM, Tobias McNulty wrote:
>>> > For me it's the trust factor (allowing someone else to decrypt and
>>> > re-encrypt all our data). This may be less of an issue for the docs
>>> > site, *if* we don't have to assign DNS authority for the whole domain
>>> > to the CDN provider.
>>> >
>>> > Tobias
>>> >
>>> >
>>> > On Wed, Feb 13, 2019, 7:47 PM Kye Russell >> > > I’ve been hearing that there are other CDN providers that offer a
>>> very comparable service for a fraction of the cost of CloudFront.
>>> > >
>>> > > Anyways, at this stage let’s not get bogged down on provider
>>> decisions. I’m curious if anyone has any general objections to a CDN of any
>>> kind.
>>> > >
>>> > > It shouldn’t be that big a deal to automatically invalidate when the
>>> docs are updated. But I’m sure there’s something I’m missing.
>>> > >
>>> > > On Thu, 14 Feb 2019 at 8:36 am, Cristiano Coelho <
>>> cristianocc...@gmail.com> wrote:
>>> > >> Consider AWS's cloudfront then :)
>>> > >>
>>> > >> El martes, 12 de febrero de 2019, 2:34:09 (UTC-5), Florian
>>> Apolloner escribió:
>>> > >>> Especially cloudflare is a service we do not want to use. as for
>>> the docs only, does the mirror on rtd work better for you? They are
>>> probably behind a CDN.
>>> > >>>
>>> > >>> Cheers,
>>> > >>> Florian
>>> > >>>
>>> > >>> On Tuesday, February 12, 2019 at 6:43:41 AM UTC+1, Cheng C wrote:
>>> >  Hi,
>>> > 
>>> >  Is it possible to utilize a CDN service for djangoproject.com,
>>> or at least on docs.djangoproject.com? The site is actually quite fast
>>> for me but I think there is still room for improvement. Cloudflare
>>> sponsored dozens of open source projects <
>>> https://developers.cloudflare.com/sponsorships/>, probably they can
>>> provide free service for django as well.
>>> > 
>>> >  Tested from Melbourne, Australia:
>>> > 
>>> >  https://www.djangoproject.com/
>>> >   Average Ping: 245ms
>>> >   Browser: 21 requests, 211KB transferred, Finish: 2.52s,
>>> DOMContentLoaded: 1.16s, Load: 1.48s
>>> > 
>>> >  https://git-scm.com/
>>> >   Average Ping: 5ms
>>> >   Browser: 42 requests, 351KB transferred, 

Re: Use CDN for djangoproject.com

[Tobias McNulty]

Fastly could be a good fit. I've reached out to see if they'd be willing to
provide a free account. If anyone on this list works at Fastly or knows
someone who does, feel free to email/introduce me off list, too.

Tobias

On Thu, Feb 14, 2019, 5:58 AM Tom Forbes  That makes sense, but in this case we are only talking about potentially
> yielding control of the docs subdomain which is not used to serve sensitive
> build artefacts?
>
> Another option is fastly.com, who support other large open source
> projects for free. They essentially give you geographically distributed
> HAProxy instances and you have a lot more control over them. I believe
> several large Linux distributions use them to serve cached apt packages.
>
> Regarding TLS termination, unfortunately any CDN we use will likely need
> to do this for the whole domain to get any benefit. The Django docs are
> text/html heavy with very few, if any, images. So the real speed benefit
> will have to come from serving that, which requires TLS termination (and
> therefore interception) at their end.
>
> On Thu, 14 Feb 2019, 06:32 Markus Holtermann, 
> wrote:
>
>> Hi all
>>
>> to elaborate on what Tobias said: we deliberately have the infrastructure
>> spread across multiple service providers: DNS registry, nameservers,
>> hosting, TLS certificate authority, … None of them have access to
>> everything. The reason is that we offer the download of the release
>> artifacts from the djangoproject.com website. And we would like to
>> ensure that the TLS termination happens by us and not some random service
>> provider. After all, Django is used by enterprises that do have some
>> restrictions on where you're allowed to download software from.
>>
>> By handing over DNS to some CDN provider, we loose the ability to ensure
>> that happens.
>>
>> That said, if there's a CDN that works as a reverse proxy and doesn't
>> require us to hand over control of DNS, I guess we could be interested in
>> moving the docs behind that.
>>
>> /Markus
>>
>> On Thu, Feb 14, 2019, at 2:22 AM, Tobias McNulty wrote:
>> > For me it's the trust factor (allowing someone else to decrypt and
>> > re-encrypt all our data). This may be less of an issue for the docs
>> > site, *if* we don't have to assign DNS authority for the whole domain
>> > to the CDN provider.
>> >
>> > Tobias
>> >
>> >
>> > On Wed, Feb 13, 2019, 7:47 PM Kye Russell > > > I’ve been hearing that there are other CDN providers that offer a
>> very comparable service for a fraction of the cost of CloudFront.
>> > >
>> > > Anyways, at this stage let’s not get bogged down on provider
>> decisions. I’m curious if anyone has any general objections to a CDN of any
>> kind.
>> > >
>> > > It shouldn’t be that big a deal to automatically invalidate when the
>> docs are updated. But I’m sure there’s something I’m missing.
>> > >
>> > > On Thu, 14 Feb 2019 at 8:36 am, Cristiano Coelho <
>> cristianocc...@gmail.com> wrote:
>> > >> Consider AWS's cloudfront then :)
>> > >>
>> > >> El martes, 12 de febrero de 2019, 2:34:09 (UTC-5), Florian Apolloner
>> escribió:
>> > >>> Especially cloudflare is a service we do not want to use. as for
>> the docs only, does the mirror on rtd work better for you? They are
>> probably behind a CDN.
>> > >>>
>> > >>> Cheers,
>> > >>> Florian
>> > >>>
>> > >>> On Tuesday, February 12, 2019 at 6:43:41 AM UTC+1, Cheng C wrote:
>> >  Hi,
>> > 
>> >  Is it possible to utilize a CDN service for djangoproject.com, or
>> at least on docs.djangoproject.com? The site is actually quite fast for
>> me but I think there is still room for improvement. Cloudflare sponsored
>> dozens of open source projects <
>> https://developers.cloudflare.com/sponsorships/>, probably they can
>> provide free service for django as well.
>> > 
>> >  Tested from Melbourne, Australia:
>> > 
>> >  https://www.djangoproject.com/
>> >   Average Ping: 245ms
>> >   Browser: 21 requests, 211KB transferred, Finish: 2.52s,
>> DOMContentLoaded: 1.16s, Load: 1.48s
>> > 
>> >  https://git-scm.com/
>> >   Average Ping: 5ms
>> >   Browser: 42 requests, 351KB transferred, Finish: 717ms,
>> DOMContentLoaded: 564ms, Load: 699ms
>> > 
>> >  Tested on Chrome with "Disable cache" checked (but not the first
>> time visit, so DNS query time might not be included).
>> > 
>> >  Best regards and thanks for all your great 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
>> 

Re: Google Summer of Code 2019

[Carlton Gibson]

Hi Shashank. 

"Sir"? That's my father, surely.  (Not "sir" ) 

We've applied as an Org. Haven't heard yet whether we'll be accepted. 

If so, proposals would be welcome. We'd then need to think about mentors. 
Good proposals will draw out people there. 

If we can get all that lined up then, yes, in principle we're accepting 
applications. 

Kind Regards,

Carlton


On Thursday, 14 February 2019 13:46:57 UTC+1, Shashank shet wrote:
>
> Hello Carlton sir,
> I have worked on Django as a part of a project and wished to ask if the 
> organization is still accepting proposals for GSoC 2019. 
>
> On Monday, February 4, 2019 at 8:25:42 PM UTC+5:30, Carlton Gibson wrote:
>>
>> And thank you Tim, yes, exactly what I need. 
>>
>> To all: 
>>
>> I will put in the org application today. We'll then see about the 
>> proposals. 
>>
>> The main thing is that we need to know who you are, and have confidence 
>> in you in order to commit to the project with you. 
>> For people to mentor you is a big commitment of time and energy. You need 
>> to demonstrate that will be well invested. 
>>
>> The way to do that is to get involved and show us who you are over the 
>> next few months. 
>> Help reproduce bugs, review patches, create patches etc. 
>> It doesn't take much before you're visible. (Really!) 
>>
>> The best way (also) to come up with project ideas is to see where there 
>> are issues already. 
>> (Much better than us providing a list.) So again, be involved. 
>>
>> If you start now, there's still lots of time, so I'm hoping. 
>>
>> Kind Regards,
>>
>> Carlton
>>
>>
>>
>>
>>
>> On Monday, 4 February 2019 15:43:39 UTC+1, Tim Graham wrote:
>>>
>>> It's a private wiki that only Django team members like Carlton can 
>>> access. It contains the information for Django to apply for GSoC.
>>>
>>> On Monday, February 4, 2019 at 9:07:40 AM UTC-5, Giuseppe De Marco wrote:

 Hi Tim,

 It returns 404 to me

 https://github.com/django/django-team-wiki/wiki/Google-Summer-of-Code-Application-Info

 Il giorno lun 4 feb 2019 alle ore 13:05 Tim Graham  
 ha scritto:

> All answers are at 
> https://github.com/django/django-team-wiki/wiki/Google-Summer-of-Code-Application-Info
>


-- 
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/96816957-08b6-4896-9bcf-f138e1dc06bb%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: Google Summer of Code 2019

[Shashank shet]

Hello Carlton sir,
I have worked on Django as a part of a project and wished to ask if the 
organization is still accepting proposals for GSoC 2019. 

On Monday, February 4, 2019 at 8:25:42 PM UTC+5:30, Carlton Gibson wrote:
>
> And thank you Tim, yes, exactly what I need. 
>
> To all: 
>
> I will put in the org application today. We'll then see about the 
> proposals. 
>
> The main thing is that we need to know who you are, and have confidence in 
> you in order to commit to the project with you. 
> For people to mentor you is a big commitment of time and energy. You need 
> to demonstrate that will be well invested. 
>
> The way to do that is to get involved and show us who you are over the 
> next few months. 
> Help reproduce bugs, review patches, create patches etc. 
> It doesn't take much before you're visible. (Really!) 
>
> The best way (also) to come up with project ideas is to see where there 
> are issues already. 
> (Much better than us providing a list.) So again, be involved. 
>
> If you start now, there's still lots of time, so I'm hoping. 
>
> Kind Regards,
>
> Carlton
>
>
>
>
>
> On Monday, 4 February 2019 15:43:39 UTC+1, Tim Graham wrote:
>>
>> It's a private wiki that only Django team members like Carlton can 
>> access. It contains the information for Django to apply for GSoC.
>>
>> On Monday, February 4, 2019 at 9:07:40 AM UTC-5, Giuseppe De Marco wrote:
>>>
>>> Hi Tim,
>>>
>>> It returns 404 to me
>>>
>>> https://github.com/django/django-team-wiki/wiki/Google-Summer-of-Code-Application-Info
>>>
>>> Il giorno lun 4 feb 2019 alle ore 13:05 Tim Graham  
>>> ha scritto:
>>>
 All answers are at 
 https://github.com/django/django-team-wiki/wiki/Google-Summer-of-Code-Application-Info

>>>

-- 
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/77cab753-bf3e-4d15-b47c-039c2be5423b%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: Use CDN for djangoproject.com

[Josh Smeaton]

Cloudflare have many SSL options, including fully encrypted and
authenticated comms all the way through (terminate and reconnect).
Typically done by having a “hidden” origin domain that also hosts a
certificate. I’m unsure if it’s possible to have both origin and front
hosting the same name so that DNS alone can decide to hit cdn or origin.

Anyway, it seems weird to me to dismiss a CDN offhand “because security”.
Especially considering the size of the providers and the expertise their
teams have.

Cloudflare (fastly, cloudfront, whatever) aren’t some “random TLS”
providers. I would probably go as far to say that putting a CDN in front of
both the docs and the release packages would likely be a net improvement in
security for users.

On Thu, 14 Feb 2019 at 21:58, Tom Forbes  wrote:

> That makes sense, but in this case we are only talking about potentially
> yielding control of the docs subdomain which is not used to serve sensitive
> build artefacts?
>
> Another option is fastly.com, who support other large open source
> projects for free. They essentially give you geographically distributed
> HAProxy instances and you have a lot more control over them. I believe
> several large Linux distributions use them to serve cached apt packages.
>
> Regarding TLS termination, unfortunately any CDN we use will likely need
> to do this for the whole domain to get any benefit. The Django docs are
> text/html heavy with very few, if any, images. So the real speed benefit
> will have to come from serving that, which requires TLS termination (and
> therefore interception) at their end.
>
> On Thu, 14 Feb 2019, 06:32 Markus Holtermann, 
> wrote:
>
>> Hi all
>>
>> to elaborate on what Tobias said: we deliberately have the infrastructure
>> spread across multiple service providers: DNS registry, nameservers,
>> hosting, TLS certificate authority, … None of them have access to
>> everything. The reason is that we offer the download of the release
>> artifacts from the djangoproject.com website. And we would like to
>> ensure that the TLS termination happens by us and not some random service
>> provider. After all, Django is used by enterprises that do have some
>> restrictions on where you're allowed to download software from.
>>
>> By handing over DNS to some CDN provider, we loose the ability to ensure
>> that happens.
>>
>> That said, if there's a CDN that works as a reverse proxy and doesn't
>> require us to hand over control of DNS, I guess we could be interested in
>> moving the docs behind that.
>>
>> /Markus
>>
>> On Thu, Feb 14, 2019, at 2:22 AM, Tobias McNulty wrote:
>> > For me it's the trust factor (allowing someone else to decrypt and
>> > re-encrypt all our data). This may be less of an issue for the docs
>> > site, *if* we don't have to assign DNS authority for the whole domain
>> > to the CDN provider.
>> >
>> > Tobias
>> >
>> >
>> > On Wed, Feb 13, 2019, 7:47 PM Kye Russell > > > I’ve been hearing that there are other CDN providers that offer a
>> very comparable service for a fraction of the cost of CloudFront.
>> > >
>> > > Anyways, at this stage let’s not get bogged down on provider
>> decisions. I’m curious if anyone has any general objections to a CDN of any
>> kind.
>> > >
>> > > It shouldn’t be that big a deal to automatically invalidate when the
>> docs are updated. But I’m sure there’s something I’m missing.
>> > >
>> > > On Thu, 14 Feb 2019 at 8:36 am, Cristiano Coelho <
>> cristianocc...@gmail.com> wrote:
>> > >> Consider AWS's cloudfront then :)
>> > >>
>> > >> El martes, 12 de febrero de 2019, 2:34:09 (UTC-5), Florian Apolloner
>> escribió:
>> > >>> Especially cloudflare is a service we do not want to use. as for
>> the docs only, does the mirror on rtd work better for you? They are
>> probably behind a CDN.
>> > >>>
>> > >>> Cheers,
>> > >>> Florian
>> > >>>
>> > >>> On Tuesday, February 12, 2019 at 6:43:41 AM UTC+1, Cheng C wrote:
>> >  Hi,
>> > 
>> >  Is it possible to utilize a CDN service for djangoproject.com, or
>> at least on docs.djangoproject.com? The site is actually quite fast for
>> me but I think there is still room for improvement. Cloudflare sponsored
>> dozens of open source projects <
>> https://developers.cloudflare.com/sponsorships/>, probably they can
>> provide free service for django as well.
>> > 
>> >  Tested from Melbourne, Australia:
>> > 
>> >  https://www.djangoproject.com/
>> >   Average Ping: 245ms
>> >   Browser: 21 requests, 211KB transferred, Finish: 2.52s,
>> DOMContentLoaded: 1.16s, Load: 1.48s
>> > 
>> >  https://git-scm.com/
>> >   Average Ping: 5ms
>> >   Browser: 42 requests, 351KB transferred, Finish: 717ms,
>> DOMContentLoaded: 564ms, Load: 699ms
>> > 
>> >  Tested on Chrome with "Disable cache" checked (but not the first
>> time visit, so DNS query time might not be included).
>> > 
>> >  Best regards and thanks for all your great work.
>> > >>
>> >
>> >
>> > >>  --
>> > >>  You 

Re: Use CDN for djangoproject.com

[Tom Forbes]

That makes sense, but in this case we are only talking about potentially
yielding control of the docs subdomain which is not used to serve sensitive
build artefacts?

Another option is fastly.com, who support other large open source projects
for free. They essentially give you geographically distributed HAProxy
instances and you have a lot more control over them. I believe several
large Linux distributions use them to serve cached apt packages.

Regarding TLS termination, unfortunately any CDN we use will likely need to
do this for the whole domain to get any benefit. The Django docs are
text/html heavy with very few, if any, images. So the real speed benefit
will have to come from serving that, which requires TLS termination (and
therefore interception) at their end.

On Thu, 14 Feb 2019, 06:32 Markus Holtermann, 
wrote:

> Hi all
>
> to elaborate on what Tobias said: we deliberately have the infrastructure
> spread across multiple service providers: DNS registry, nameservers,
> hosting, TLS certificate authority, … None of them have access to
> everything. The reason is that we offer the download of the release
> artifacts from the djangoproject.com website. And we would like to ensure
> that the TLS termination happens by us and not some random service
> provider. After all, Django is used by enterprises that do have some
> restrictions on where you're allowed to download software from.
>
> By handing over DNS to some CDN provider, we loose the ability to ensure
> that happens.
>
> That said, if there's a CDN that works as a reverse proxy and doesn't
> require us to hand over control of DNS, I guess we could be interested in
> moving the docs behind that.
>
> /Markus
>
> On Thu, Feb 14, 2019, at 2:22 AM, Tobias McNulty wrote:
> > For me it's the trust factor (allowing someone else to decrypt and
> > re-encrypt all our data). This may be less of an issue for the docs
> > site, *if* we don't have to assign DNS authority for the whole domain
> > to the CDN provider.
> >
> > Tobias
> >
> >
> > On Wed, Feb 13, 2019, 7:47 PM Kye Russell  > > I’ve been hearing that there are other CDN providers that offer a very
> comparable service for a fraction of the cost of CloudFront.
> > >
> > > Anyways, at this stage let’s not get bogged down on provider
> decisions. I’m curious if anyone has any general objections to a CDN of any
> kind.
> > >
> > > It shouldn’t be that big a deal to automatically invalidate when the
> docs are updated. But I’m sure there’s something I’m missing.
> > >
> > > On Thu, 14 Feb 2019 at 8:36 am, Cristiano Coelho <
> cristianocc...@gmail.com> wrote:
> > >> Consider AWS's cloudfront then :)
> > >>
> > >> El martes, 12 de febrero de 2019, 2:34:09 (UTC-5), Florian Apolloner
> escribió:
> > >>> Especially cloudflare is a service we do not want to use. as for the
> docs only, does the mirror on rtd work better for you? They are probably
> behind a CDN.
> > >>>
> > >>> Cheers,
> > >>> Florian
> > >>>
> > >>> On Tuesday, February 12, 2019 at 6:43:41 AM UTC+1, Cheng C wrote:
> >  Hi,
> > 
> >  Is it possible to utilize a CDN service for djangoproject.com, or
> at least on docs.djangoproject.com? The site is actually quite fast for
> me but I think there is still room for improvement. Cloudflare sponsored
> dozens of open source projects <
> https://developers.cloudflare.com/sponsorships/>, probably they can
> provide free service for django as well.
> > 
> >  Tested from Melbourne, Australia:
> > 
> >  https://www.djangoproject.com/
> >   Average Ping: 245ms
> >   Browser: 21 requests, 211KB transferred, Finish: 2.52s,
> DOMContentLoaded: 1.16s, Load: 1.48s
> > 
> >  https://git-scm.com/
> >   Average Ping: 5ms
> >   Browser: 42 requests, 351KB transferred, Finish: 717ms,
> DOMContentLoaded: 564ms, Load: 699ms
> > 
> >  Tested on Chrome with "Disable cache" checked (but not the first
> time visit, so DNS query time might not be included).
> > 
> >  Best regards and thanks for all your great 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/548db807-647f-4d0b-99c2-f9f229f7175e%40googlegroups.com
> <
> https://groups.google.com/d/msgid/django-developers/548db807-647f-4d0b-99c2-f9f229f7175e%40googlegroups.com?utm_medium=email_source=footer
> >.
> > >>  For more options, visit https://groups.google.com/d/optout.
> > >>
> > >
> >
> >
> > >  --
> > >  You received this message because you are subscribed to the