Re: [GSoC 2013] contribute to django-deployer for deploying django to PaaS easily

[Jacob Kaplan-Moss]

While I share some of Andrew's concerns, I do think this is still a
fairly good topic for GSoC.

However, I think the only way it could happen would be if Nate wants
to mentor the project; Nate, can you mentor? If so, you should hook up
with Andrew and make sure you apply to be a mentor so we can have you
added before the review process.

Jacob

On Thu, May 2, 2013 at 4:11 AM, Andrew Godwin  wrote:
> I feel like the deployment problem is one that cannot be solved in a mere 12
> weeks and I'm not sure django-deployer is the right approach to encourage
> for this - it sits at the wrong level of abstraction and looks pretty
> fragile, and I'd be hesitant to put any sort of official emphasis on it
> without a lot of my qualms being answered. In particular, it appears to be
> sitting at the lowest-common-denominator level of the various feature sets
> and looks pretty immature.
>
> I'm not sure I could accept this without a much clearer idea of what's going
> to happen and a very clear focus on what section of our user base it will
> help. Deployment isn't something there can be a single solution (or even
> pattern) for, and I think encouraging that could be a bad idea.
>
> Andrew
>
>
> On Wed, May 1, 2013 at 8:20 PM, Nate Aune  wrote:
>>
>> Hi Russell and Florian,
>>
>> A bit late to the party, but hopefully there's still time for this GSoC
>> proposal to be considered. I'm the maintainer of django-deployer. It was
>> initiated at the DjangoCon 2012 sprint and recently revisited at the PyCon
>> 2013 sprint. The overarching goal of django-deployer is to make it easier to
>> get Django deployed. So far the focus has been on deploying to PaaS
>> providers, because they require little to no sysadmin skills, and have the
>> added benefit of being free for small projects.
>>
>> django-deployer is the sister project PaaS Cheatsheet, a larger
>> documentation project that I've started recently. PaaS Cheatsheet is a guide
>> for how to get a Django/Python deployed on various PaaS providers.
>>
>> The way django-deployer works is by asking a series of questions about
>> your Django project, and then generates a generic deploy.yml file that
>> captures all of your project's requirements. When you choose a particular
>> PaaS provider, django-deployer then translates the requirements defined in
>> the deploy.yml file and generates configuration files for that specific PaaS
>> provider.
>>
>> I met Colin (a student in Taiwan) at the PyCon sprint, and he was
>> responsible for single-handedly adding Google App Engine support to
>> django-deployer. He brought considerable expertise to our sprint team, and
>> shipped working code within a matter of hours. Since returning from PyCon,
>> we've been working remotely together, and he has continued to be a dedicated
>> contributor to the project. I have utmost confidence in his abilities to add
>> even more cool features and improve code quality of the django-deployer tool
>> if this project is accepted into GSoC.
>>
>> English is a second language for Colin, so he may have had some
>> difficulties in defending his proposal, so please allow me to step in and
>> clarify a few things.
>>
>>>
>>> Firstly, I'm not familiar with Django-deploy; but from a quick inspection
>>> of the project page it doesn't appear that anyone in the Django core team is
>>> on the committee list. In order for you to have this proposal accepted as
>>> part of the GSoC, you'll need to secure agreement from the project
>>> maintainers of Django-deploy that they want the help your offering, that
>>> your project proposal is sound, and that they're willing to commit to
>>> applying any patches you produce.
>>
>>
>> As stated above, I'm willing to work closely with Colin to meet the
>> objectives described in the proposal.
>>
>>> Secondly, you haven't provided any timelines for your proposal. My
>>> immediate reaction is that you're proposing a lot of work for a student to
>>> complete in 12 weeks. For example, writing a fully tested and documented
>>> database backend strikes me as a 12 week project in itself - yet this is
>>> apparently just one line item in one part of your project proposal.
>>
>>
>> I think you may have misread that part of proposal. He's not proposing to
>> write a database backend.  There is already one provided by the Google App
>> Engine SDK, so we're simply incorporating that into the configuration
>> scripts (i.e. adding a settings_appengine.py that substitutes the DATABASE
>> setting value).
>>>
>>>
>>> Lastly, your project proposal is very light on details. You're proposing
>>> a lot of ideas, but you haven't really specified anything beyond "I'm going
>>> to do it". Are there APIs that need to be specified? If, in the case of
>>> something like a database backend, the APi is already specified, are there
>>> going to be any complications in satisfying the API? We need a lot more
>>> detail before we will be able to judge if you understand 

Re: Improve annotation and aggregation

[Andre Terra]

May I recommend you browse Trac and take a look at the pending tickets
regarding aggregation?

This query should give you enough food for thought: http://goo.gl/vvraU

It is my understanding that Anssi Kääriäinen is working on an ORM refactor,
so speaking to him seems fundamental if you really want to move forward
with this, even with the imminent deadline. Some of the tickets you'll find
in that query may even have patches, but with the ongoing refactoring it
seems as if they're shooting at a moving target.


Cheers.
AT


On Thu, May 2, 2013 at 10:30 PM, Russell Keith-Magee <
russ...@keith-magee.com> wrote:

>
> On Fri, May 3, 2013 at 4:31 AM, nimesh ghelani wrote:
>
>> Hey,
>> Will like reviews on my proposal
>>
>> https://gist.github.com/nims11/dbd2f52677377eb60c07
>>
>> Hi Nimesh,
>
> At present, this isn't an especially compelling proposal.
>
> The bulk of what you're proposing is extremely vague. The #10929 default
> NULL issue is well known and understood, but detail on your other proposal
> goes no further than "should be simpler". We agree. Now, how are you going
> to do that? You haven't given an API proposal, and you're not previously
> known to the wider community, so we can't judge whether you have good API
> design skills, or whether you've looked at any of the internals to
> determine if what you're proposing is technically feasible given the
> existing infrastructure.
>
> On top of that, based on no experience with the query internals, you've
> assumed that you'll be able to understand the internals of Django's query
> engine, and then design and get consensus on an API plan in a 2 week
> window. That's… ambitious.
>
> Then you've got a 7 week block to implement this plan. This sort of
> granularity gives us no confidence that you in any way understand the task
> ahead of you. If you can't provide a plan at the granularity of days, or a
> week at the *most*, then it's safe to say you haven't actually thought in
> detail about the complexity of the problem you're proposing to solve.
>
> You're proposing a deep dive into the internals of Django's query
> infrastructure. Committing to being a mentor for the GSoC is a big
> commitment, and there is a limited number of people who are in a position
> to mentor you on this project. When combined with the vagueness of what
> you're proposing, you haven't exactly inspired the confidence you'll need
> to convince someone to commit to mentoring you.
>
> If you want to be selected for the GSoC, you'll need to provide a lot more
> details -- most importantly, evidence that you've thought about the problem
> at a level beyond "this looks like a nice problem".
>
> Yours,
> Russ Magee %-)
>
>  --
> You received this message because you are subscribed to the Google Groups
> "Django developers" 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 http://groups.google.com/group/django-developers?hl=en
> .
> For more options, visit https://groups.google.com/groups/opt_out.
>
>
>

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers" 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 http://groups.google.com/group/django-developers?hl=en.
For more options, visit https://groups.google.com/groups/opt_out.

Re: Improve annotation and aggregation

[Russell Keith-Magee]

On Fri, May 3, 2013 at 4:31 AM, nimesh ghelani wrote:

> Hey,
> Will like reviews on my proposal
>
> https://gist.github.com/nims11/dbd2f52677377eb60c07
>
> Hi Nimesh,

At present, this isn't an especially compelling proposal.

The bulk of what you're proposing is extremely vague. The #10929 default
NULL issue is well known and understood, but detail on your other proposal
goes no further than "should be simpler". We agree. Now, how are you going
to do that? You haven't given an API proposal, and you're not previously
known to the wider community, so we can't judge whether you have good API
design skills, or whether you've looked at any of the internals to
determine if what you're proposing is technically feasible given the
existing infrastructure.

On top of that, based on no experience with the query internals, you've
assumed that you'll be able to understand the internals of Django's query
engine, and then design and get consensus on an API plan in a 2 week
window. That's… ambitious.

Then you've got a 7 week block to implement this plan. This sort of
granularity gives us no confidence that you in any way understand the task
ahead of you. If you can't provide a plan at the granularity of days, or a
week at the *most*, then it's safe to say you haven't actually thought in
detail about the complexity of the problem you're proposing to solve.

You're proposing a deep dive into the internals of Django's query
infrastructure. Committing to being a mentor for the GSoC is a big
commitment, and there is a limited number of people who are in a position
to mentor you on this project. When combined with the vagueness of what
you're proposing, you haven't exactly inspired the confidence you'll need
to convince someone to commit to mentoring you.

If you want to be selected for the GSoC, you'll need to provide a lot more
details -- most importantly, evidence that you've thought about the problem
at a level beyond "this looks like a nice problem".

Yours,
Russ Magee %-)

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers" 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 http://groups.google.com/group/django-developers?hl=en.
For more options, visit https://groups.google.com/groups/opt_out.

Improve annotation and aggregation

[nimesh ghelani]

Hey,
Will like reviews on my proposal

https://gist.github.com/nims11/dbd2f52677377eb60c07

Thanks and Regards,
Nimesh Ghelani

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers" 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 http://groups.google.com/group/django-developers?hl=en.
For more options, visit https://groups.google.com/groups/opt_out.

Re:

[Karen Tracey]

You posted this here less than an hour after posting on django-users, that
hardly seems time enough to consider it "ignored" there.

Also, you might want to include a subject in your emails, particularly for
high-traffic lists I would not be surprised if some people simply scan the
subjects for stuff that they think might be interesting or something they
may be able to answer. items with "(no subject)" as the subject may very
well get fewer readers than a subject that actually describes the
post/question/whatever.

Karen

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers" 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 http://groups.google.com/group/django-developers?hl=en.
For more options, visit https://groups.google.com/groups/opt_out.

Re: [GSoC 2013] contribute to django-deployer for deploying django to PaaS easily

[LittleQ@NCCU, Taiwan]

Hello, Andrew

On Thursday, May 2, 2013 4:11:35 PM UTC+8, Andrew Godwin wrote:
>
> I feel like the deployment problem is one that cannot be solved in a mere 
> 12 weeks and I'm not sure django-deployer is the right approach to 
> encourage for this - it sits at the wrong level of abstraction and looks 
> pretty fragile, and I'd be hesitant to put any sort of official emphasis on 
> it without a lot of my qualms being answered. In particular, it appears to 
> be sitting at the lowest-common-denominator level of the various feature 
> sets and looks pretty immature.
>

I'm not going to build the whole django-deployer as description in my 
proposal, django-deployer is a running project already and I started 
contributing recently, the tasks I wanna do is just made django-deployer 
support GAE and provide a better connection to django. For improving my 
proposal, I already reduced the tasks listed in my proposal and listed out 
more detail.

could you please list out all your qualms? then maybe I can know what can I 
do in the next.
 

>
> I'm not sure I could accept this without a much clearer idea of what's 
> going to happen and a very clear focus on what section of our user base it 
> will help. Deployment isn't something there can be a single solution (or 
> even pattern) for, and I think encouraging that could be a bad idea.
>

The user base which django-deployer want to help is "people who are trying 
deploy their django app onto any PaaS", and for minimizing the effort from 
who already know how to deploy django onto some PaaS to provide the 
solution to others.

I agree with you that deployment isn't something could be a single 
solution, the ease of deployment should be provided by PaaS provider but 
not django or any django third-party library, but I think it's impossible 
to ask each PaaS provider to make "perfect django deployment flow" to each 
django user.

actually this project helps me a lot when I went back from PyCon, I have a 
running django project on GAE and it works well.

please feel free to ask me question about the proposal or give out more 
feedback, I will appreciate for that, thank you.


- Colin : )

I really hope I can get involved GSoC with Django community, Django is 
always one of my favorite project, for now maybe I'm not qualified to do 
some task for django-core, but I think I could improve this project to get 
more people use Django easily.
 

>
> Andrew
>
>
> On Wed, May 1, 2013 at 8:20 PM, Nate Aune  > wrote:
>
>> Hi Russell and Florian,
>>
>> A bit late to the party, but hopefully there's still time for this GSoC 
>> proposal to be considered. I'm the maintainer of 
>> django-deployer. 
>> It was initiated at the DjangoCon 2012 sprint and recently revisited at the 
>> PyCon 2013 sprint. The overarching goal of django-deployer is to make it 
>> easier to get Django deployed. So far the focus has been on deploying to 
>> PaaS providers, because they require little to no sysadmin skills, and have 
>> the added benefit of being free for small projects.
>>
>> django-deployer is the sister project PaaS Cheatsheet, a larger 
>> documentation project that I've started recently. PaaS 
>> Cheatsheetis a guide for how to get a 
>> Django/Python deployed on various PaaS 
>> providers. 
>>
>> The way django-deployer works is by asking a series of questions about 
>> your Django project, and then generates a generic deploy.yml file that 
>> captures all of your project's requirements. When you choose a particular 
>> PaaS provider, django-deployer then translates the requirements defined in 
>> the deploy.yml file and generates configuration files for that specific 
>> PaaS provider.
>>
>> I met Colin (a student in Taiwan) at the PyCon sprint, and he was 
>> responsible for single-handedly adding Google App Engine support to 
>> django-deployer. He brought considerable expertise to our sprint team, and 
>> shipped working code within a matter of hours. Since returning from PyCon, 
>> we've been working remotely together, and he has continued to be a 
>> dedicated contributor to the project. I have utmost confidence in his 
>> abilities to add even more cool features and improve code quality of the 
>> django-deployer tool if this project is accepted into GSoC. 
>>
>> English is a second language for Colin, so he may have had some 
>> difficulties in defending his proposal, so please allow me to step in and 
>> clarify a few things.
>>  
>>
>>> Firstly, I'm not familiar with Django-deploy; but from a quick 
>>> inspection of the project page it doesn't appear that anyone in the Django 
>>> core team is on the committee list. In order for you to have this proposal 
>>> accepted as part of the GSoC, you'll need to secure agreement from the 
>>> project maintainers of Django-deploy that they want the help your offering, 
>>> that your project proposal is sound, and that they're willing to commit 

Re:

[Alex Gaynor]

I'll also second that, in addition to the methodological flaws I see, they
don't do any testing of running Django under PyPy, which has seen
significant speed boosts in the wild.

Alex


On Thu, May 2, 2013 at 10:50 AM, Jacob Kaplan-Moss wrote:

> On Thu, May 2, 2013 at 1:34 PM, Michał Nowotka  wrote:
> > http://www.techempower.com/benchmarks/#section=data-r4 django
> performance is
> > really bad comparing to other popular web frameworks. Are there any
> plans to
> > change this situation?
>
> First, there are some very serious problems with those "benchmarks" --
> they aren't really comparing apples to apples at all. There's some
> interesting things to dig into with that work, but stating
> categorically that this "proves" that Django is "slow" is... a
> stretch.
>
> Second, raw speed isn't everything. Scalability, ease of use,
> suitability, and many other factors play into the decisions we make
> about technology. If we only cared about raw speed, we'd all still be
> writing assembly.
>
> Finally, of course we care about performance, and we're constantly
> monitoring and improving Django's speed (see
> https://github.com/jacobian/djangobench, for example). If you'd like
> to help, there's plenty of low-hanging fruit, feel free to dive in.
>
> But let's not pay *too* much attention to a badly-designed study with
> unclear goals and intentions.
>
> Jacob
>
> --
> You received this message because you are subscribed to the Google Groups
> "Django developers" 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 http://groups.google.com/group/django-developers?hl=en
> .
> For more options, visit https://groups.google.com/groups/opt_out.
>
>
>


-- 
"I disapprove of what you say, but I will defend to the death your right to
say it." -- Evelyn Beatrice Hall (summarizing Voltaire)
"The people's good is the highest law." -- Cicero
GPG Key fingerprint: 125F 5C67 DFE9 4084

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers" 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 http://groups.google.com/group/django-developers?hl=en.
For more options, visit https://groups.google.com/groups/opt_out.

Fwd:

[Jacob Kaplan-Moss]

On Thu, May 2, 2013 at 1:34 PM, Michał Nowotka  wrote:
> http://www.techempower.com/benchmarks/#section=data-r4 django performance is
> really bad comparing to other popular web frameworks. Are there any plans to
> change this situation?

First, there are some very serious problems with those "benchmarks" --
they aren't really comparing apples to apples at all. There's some
interesting things to dig into with that work, but stating
categorically that this "proves" that Django is "slow" is... a
stretch.

Second, raw speed isn't everything. Scalability, ease of use,
suitability, and many other factors play into the decisions we make
about technology. If we only cared about raw speed, we'd all still be
writing assembly.

Finally, of course we care about performance, and we're constantly
monitoring and improving Django's speed (see
https://github.com/jacobian/djangobench, for example). If you'd like
to help, there's plenty of low-hanging fruit, feel free to dive in.

But let's not pay *too* much attention to a badly-designed study with
unclear goals and intentions.

Jacob

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers" 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 http://groups.google.com/group/django-developers?hl=en.
For more options, visit https://groups.google.com/groups/opt_out.

[no subject]

[Michał Nowotka]

I'm sorry for crossposting this question but my emails are somehow ignored
on django-users list...

According to that webpage:
http://www.techempower.com/benchmarks/#section=data-r4 django performance
is really bad comparing to other popular web frameworks. Are there any
plans to change this situation?

Regards,
Michal Nowotka

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers" 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 http://groups.google.com/group/django-developers?hl=en.
For more options, visit https://groups.google.com/groups/opt_out.

Re: GSoC proposal for the "Adding New Feature of Dynamic Forms and Enhancement of Django-forms"

[Satinderpal Singh]

On Thu, May 2, 2013 at 7:09 PM, Jacob Kaplan-Moss  wrote:
> Hi Satinderpal -
>
> Thanks for your effort! Unfortunately, I think you've still got a long
> way to go.
>
> Your proposal is fundamentally quite vague. You seem to understand
> some of the problems with the current forms API, but I really can't
> tell exactly what you plan to do about it. The actual meat of your
> proposal ("Goal") is a scant two paragraphs that doesn't really go
> into any detail about what you're proposing. There's something about
> additional attributes, and then a vague notion about dynamic forms,
> but that's it. You need to be a *lot* more specific and in depth.
>
> There's been quite a bit of discussion around forms these last few
> days -- see especially the posts the by Carl and Russ -- but you
> haven't really addressed the concerns raised in those threads. Again,
> you need to really demonstrate you understand what you're proposing to
> do.
>
> A previous summer of code forms project failed; what have you learned
> from that, and what makes your proposal different?
>
> Moving on to the timeline, you need to be more specific here, as well.
> For example, you say you need to spend two weeks "adding the template
> widgets". OK, so what about that project takes two weeks? What does
> "adding widgets" mean? Which widgets? Is there an order to what you
> plan to add? Some groundwork to lay first? Etc. You need more detail
> here, too.
>
> Then you go on to say that you plan to spend two months on
> "miscellaneous work". I'm sorry, but we're not going to mentor a
> project that sets aside two months for "miscellaneous".
>
> One week is about *minimum* amount of granularity you should have
> here; anything rougher shows you haven't thought through the steps
> clearly enough.
>
> You've also left testing and documentation until the end, which also
> isn't OK. If you've spent any time around the Django project you
> already know that testing and documentation are something we take
> incredibly seriously. They have to be do at the same time as the code;
> they're *not* an afterthought. You should writing tests and docs along
> with -- or even before -- your code.
>
> I hope this gives you some good ideas on how you might be able to
> improve your proposal into something we could accept. As I've said
> before, this is an area that really needs some work, so I would love
> to see a GSoC project tackle it.  But I can't accept a proposal on
> faith; I need to see that it's something with a realistic chance of
> success.
>
> Good luck,
>
Thanks Jacob for your feedback and valuable suggestions, as i am very
late on this project but i'll try my best to take your suggestions in
account and will try my best to improve  the proposal.
>
> On Thu, May 2, 2013 at 8:36 AM, Satinderpal Singh
>  wrote:
>> Given below is the link for my proposal for the GSoC 2013, please give
>> me the feedback about the proposal.
>> https://docs.google.com/document/d/1SirpfF0KXGq-GGU9iAhuEi1IbVOuXNzj8LKrLG1_1zQ/edit
>>
>> --
>> Satinderpal Singh
>> http://devplace.in/~satinder/wordpress/
>> http://satindergoraya.blogspot.in/
>> http://satindergoraya91.blogspot.in/
>>
>> --
>> You received this message because you are subscribed to the Google Groups 
>> "Django developers" 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 http://groups.google.com/group/django-developers?hl=en.
>> For more options, visit https://groups.google.com/groups/opt_out.
>>
>>
>
> --
> You received this message because you are subscribed to the Google Groups 
> "Django developers" 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 http://groups.google.com/group/django-developers?hl=en.
> For more options, visit https://groups.google.com/groups/opt_out.
>
>



--
Satinderpal Singh
http://devplace.in/~satinder/wordpress/
http://satindergoraya.blogspot.in/
http://satindergoraya91.blogspot.in/

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers" 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 http://groups.google.com/group/django-developers?hl=en.
For more options, visit https://groups.google.com/groups/opt_out.

Re: Django 1.6 release timeline

[Jacob Kaplan-Moss]

On Thu, May 2, 2013 at 4:42 AM, Aymeric Augustin
 wrote:
> Shouldn't we push the alpha to May 23rd, all the more since we plan to fork
> the stable/1.6.x branch at the beta?

That sounds reasonable; give us a chance to get any work done at
DjangoCon Europe into the tree before we roll the alpha.

So, revised schedule:

Alpha: May 23
Beta: June 27
RC: Aug 8
Final: as early as Aug 15, or later if more RCs are needed.

(Same as the original, just plus an extra week).

Jacob

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers" 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 http://groups.google.com/group/django-developers?hl=en.
For more options, visit https://groups.google.com/groups/opt_out.

Re: GSoC proposal for the "Adding New Feature of Dynamic Forms and Enhancement of Django-forms"

[Jacob Kaplan-Moss]

Hi Satinderpal -

Thanks for your effort! Unfortunately, I think you've still got a long
way to go.

Your proposal is fundamentally quite vague. You seem to understand
some of the problems with the current forms API, but I really can't
tell exactly what you plan to do about it. The actual meat of your
proposal ("Goal") is a scant two paragraphs that doesn't really go
into any detail about what you're proposing. There's something about
additional attributes, and then a vague notion about dynamic forms,
but that's it. You need to be a *lot* more specific and in depth.

There's been quite a bit of discussion around forms these last few
days -- see especially the posts the by Carl and Russ -- but you
haven't really addressed the concerns raised in those threads. Again,
you need to really demonstrate you understand what you're proposing to
do.

A previous summer of code forms project failed; what have you learned
from that, and what makes your proposal different?

Moving on to the timeline, you need to be more specific here, as well.
For example, you say you need to spend two weeks "adding the template
widgets". OK, so what about that project takes two weeks? What does
"adding widgets" mean? Which widgets? Is there an order to what you
plan to add? Some groundwork to lay first? Etc. You need more detail
here, too.

Then you go on to say that you plan to spend two months on
"miscellaneous work". I'm sorry, but we're not going to mentor a
project that sets aside two months for "miscellaneous".

One week is about *minimum* amount of granularity you should have
here; anything rougher shows you haven't thought through the steps
clearly enough.

You've also left testing and documentation until the end, which also
isn't OK. If you've spent any time around the Django project you
already know that testing and documentation are something we take
incredibly seriously. They have to be do at the same time as the code;
they're *not* an afterthought. You should writing tests and docs along
with -- or even before -- your code.

I hope this gives you some good ideas on how you might be able to
improve your proposal into something we could accept. As I've said
before, this is an area that really needs some work, so I would love
to see a GSoC project tackle it.  But I can't accept a proposal on
faith; I need to see that it's something with a realistic chance of
success.

Good luck,

Jacob

On Thu, May 2, 2013 at 8:36 AM, Satinderpal Singh
 wrote:
> Given below is the link for my proposal for the GSoC 2013, please give
> me the feedback about the proposal.
> https://docs.google.com/document/d/1SirpfF0KXGq-GGU9iAhuEi1IbVOuXNzj8LKrLG1_1zQ/edit
>
> --
> Satinderpal Singh
> http://devplace.in/~satinder/wordpress/
> http://satindergoraya.blogspot.in/
> http://satindergoraya91.blogspot.in/
>
> --
> You received this message because you are subscribed to the Google Groups 
> "Django developers" 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 http://groups.google.com/group/django-developers?hl=en.
> For more options, visit https://groups.google.com/groups/opt_out.
>
>

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers" 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 http://groups.google.com/group/django-developers?hl=en.
For more options, visit https://groups.google.com/groups/opt_out.

Re: [GSoC 2013] Better, smarter forms

[Nicolas Bouliane]

These are pretty clever ideas that would have been useful indeed. I'll find 
some time to peruse these tickets and revise my proposal.

On Wednesday, May 1, 2013 12:45:11 PM UTC-4, Nicolas Bouliane wrote:
>
> Linked here is my proposal for the 2013 Google Summer of Code. As 
> suggested by Jacob Kaplan-Moss, I am in the process of reviewing it to 
> include timelines and more detailed information about my skillset.
>
> Nonetheless, I would really appreciate to have your feedback regarding the 
> propositions contained inside. I count on your experience to confirm that 
> my perception of the Forms API is accurate, and my proposal sensible.
>
> The proposal in question: 
> https://docs.google.com/document/d/1J3EwocIzf6WHeD80EUfssXpdVFapkrEzdjMq5V4e6Dk/edit?usp=sharing
>

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers" 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 http://groups.google.com/group/django-developers?hl=en.
For more options, visit https://groups.google.com/groups/opt_out.

Re: GSOC: Deadline soon!

[Nicolas Bouliane]

Thank you for your kind words! I will try to find a few hours to correctly
edit it.

On Wed, May 1, 2013 at 8:14 PM, Russell Keith-Magee  wrote:

> Hi Nicholas,
>
> I agree that there's a lot of overlap between your proposal and
> django-floppyforms -- but I still think there's some scope for a very
> interesting GSoC project. There may be only 2 days left, but that's still
> time for a couple more revisions before the deadline.
>
> I'll leave some comments on the thread where you provided your proposal.
>
> Yours,
> Russ Magee %-)
>
> On Thu, May 2, 2013 at 3:47 AM, Nicolas Bouliane <
> cont...@nicolasbouliane.com> wrote:
>
>> Yes indeed! I heard about it around the April 27. With a few more days
>> left, I might have been able to review my proposal, but I will simply
>> concentrate on finding work this summer. I* *would still love to have my
>> proposal chosen, but I cannot put all of my eggs in that basket.
>>
>> On Wed, May 1, 2013 at 3:41 PM, Carl Meyer  wrote:
>>
>>>  On 05/01/2013 01:38 PM, Nicolas Bouliane wrote:
>>> > It seems that I have underestimated the barrier of entry to the Google
>>> > Summer of Code. With so many hoops to jump through and very little time
>>> > left, I will not play against the odds.
>>>
>>> I understand; it is late in the process to be starting on a proposal.
>>>
>>> > I still look forward to contributing to Django, but not as a GSoC
>>> student.
>>>
>>> Glad to hear it - look forward to working with you as a contributor!
>>>
>>> Carl
>>>
>>> --
>>> You received this message because you are subscribed to a topic in the
>>> Google Groups "Django developers" group.
>>> To unsubscribe from this topic, visit
>>> https://groups.google.com/d/topic/django-developers/xrP6-Fx0Jbs/unsubscribe?hl=en
>>> .
>>> To unsubscribe from this group and all its topics, 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
>>> http://groups.google.com/group/django-developers?hl=en.
>>> For more options, visit https://groups.google.com/groups/opt_out.
>>>
>>>
>>>
>>
>>
>> --
>> *Nicolas Bouliane*
>> (450) 577-1663 · nicolasbouliane.com
>>
>> --
>> You received this message because you are subscribed to the Google Groups
>> "Django developers" 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
>> http://groups.google.com/group/django-developers?hl=en.
>> For more options, visit https://groups.google.com/groups/opt_out.
>>
>>
>>
>
>  --
> You received this message because you are subscribed to a topic in the
> Google Groups "Django developers" group.
> To unsubscribe from this topic, visit
> https://groups.google.com/d/topic/django-developers/xrP6-Fx0Jbs/unsubscribe?hl=en
> .
> To unsubscribe from this group and all its topics, 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 http://groups.google.com/group/django-developers?hl=en
> .
> For more options, visit https://groups.google.com/groups/opt_out.
>
>
>



-- 
*Nicolas Bouliane*
(450) 577-1663 · nicolasbouliane.com

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers" 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 http://groups.google.com/group/django-developers?hl=en.
For more options, visit https://groups.google.com/groups/opt_out.

Re: Django 1.6 release timeline

[Aymeric Augustin]

2013/5/2 Andrew Godwin 

> get something together for DjangoCon EU


That's a good point. DjangoCon EU sprints are on May 18-19th.

Shouldn't we push the alpha to May 23rd, all the more since we plan to fork
the stable/1.6.x branch at the beta?

-- 
Aymeric.

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers" 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 http://groups.google.com/group/django-developers?hl=en.
For more options, visit https://groups.google.com/groups/opt_out.

Re: Django 1.6 release timeline

[Andrew Godwin]

I'm happy with this - I doubt schema alteration will be mergeable by the
15th (though I'm trying to get something together for DjangoCon EU) and I
want to encourage smaller release cycles. And the new transaction stuff is
great, damnit, we should ship that.

Andrew


On Tue, Apr 30, 2013 at 4:45 PM, Carl Meyer  wrote:

> Hi Shai,
>
> On 04/30/2013 04:38 PM, Shai Berger wrote:
> > On Tuesday 30 April 2013, Jacob Kaplan-Moss wrote:
> >> Hi folks -
> >>
> >> Unless there are strong objections, here's what I'm thinking for the
> >> Django 1.6 release timeline:
> >>
> >> Alpha: May 16
> >> Beta: June 20
> >> RC: Aug 1
> >> Final: as early as Aug 8, or later if more RCs are needed.
> >>
> > I see one issue with this: According to current procedures, if this
> timeline
> > is followed, support for 1.4 will be dropped less than 6 months after the
> > release of 1.5. At least for some of us (which, as I mentioned earlier
> on the
> > list, only moved to 1.4 when the 1.5 release forced us to), this may be
> a bit
> > of a problem.
>
> Yes, thanks for bringing this up. The core team discussed this at PyCon
> and I believe we had general agreement that if we achieve faster
> releases we'll need to extend support longer, at least for certain
> "long-term support" releases (a category which would probably be
> retroactively applied to 1.4). We haven't hammered out the details of
> the new policy yet, but I think it's safe to say that if we do release
> 1.6 on the proposed schedule, we won't drop support for 1.4 at that time.
>
> Carl
>
> --
> You received this message because you are subscribed to the Google Groups
> "Django developers" 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 http://groups.google.com/group/django-developers?hl=en
> .
> For more options, visit https://groups.google.com/groups/opt_out.
>
>
>

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers" 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 http://groups.google.com/group/django-developers?hl=en.
For more options, visit https://groups.google.com/groups/opt_out.

Re: [GSoC 2013] contribute to django-deployer for deploying django to PaaS easily

[Andrew Godwin]

I feel like the deployment problem is one that cannot be solved in a mere
12 weeks and I'm not sure django-deployer is the right approach to
encourage for this - it sits at the wrong level of abstraction and looks
pretty fragile, and I'd be hesitant to put any sort of official emphasis on
it without a lot of my qualms being answered. In particular, it appears to
be sitting at the lowest-common-denominator level of the various feature
sets and looks pretty immature.

I'm not sure I could accept this without a much clearer idea of what's
going to happen and a very clear focus on what section of our user base it
will help. Deployment isn't something there can be a single solution (or
even pattern) for, and I think encouraging that could be a bad idea.

Andrew


On Wed, May 1, 2013 at 8:20 PM, Nate Aune  wrote:

> Hi Russell and Florian,
>
> A bit late to the party, but hopefully there's still time for this GSoC
> proposal to be considered. I'm the maintainer of 
> django-deployer.
> It was initiated at the DjangoCon 2012 sprint and recently revisited at the
> PyCon 2013 sprint. The overarching goal of django-deployer is to make it
> easier to get Django deployed. So far the focus has been on deploying to
> PaaS providers, because they require little to no sysadmin skills, and have
> the added benefit of being free for small projects.
>
> django-deployer is the sister project PaaS Cheatsheet, a larger
> documentation project that I've started recently. PaaS 
> Cheatsheetis a guide for how to get a 
> Django/Python deployed on various PaaS
> providers.
>
> The way django-deployer works is by asking a series of questions about
> your Django project, and then generates a generic deploy.yml file that
> captures all of your project's requirements. When you choose a particular
> PaaS provider, django-deployer then translates the requirements defined in
> the deploy.yml file and generates configuration files for that specific
> PaaS provider.
>
> I met Colin (a student in Taiwan) at the PyCon sprint, and he was
> responsible for single-handedly adding Google App Engine support to
> django-deployer. He brought considerable expertise to our sprint team, and
> shipped working code within a matter of hours. Since returning from PyCon,
> we've been working remotely together, and he has continued to be a
> dedicated contributor to the project. I have utmost confidence in his
> abilities to add even more cool features and improve code quality of the
> django-deployer tool if this project is accepted into GSoC.
>
> English is a second language for Colin, so he may have had some
> difficulties in defending his proposal, so please allow me to step in and
> clarify a few things.
>
>
>> Firstly, I'm not familiar with Django-deploy; but from a quick inspection
>> of the project page it doesn't appear that anyone in the Django core team
>> is on the committee list. In order for you to have this proposal accepted
>> as part of the GSoC, you'll need to secure agreement from the project
>> maintainers of Django-deploy that they want the help your offering, that
>> your project proposal is sound, and that they're willing to commit to
>> applying any patches you produce.
>
>
> As stated above, I'm willing to work closely with Colin to meet the
> objectives described in the proposal.
>
> Secondly, you haven't provided any timelines for your proposal. My
>> immediate reaction is that you're proposing a lot of work for a student to
>> complete in 12 weeks. For example, writing a fully tested and documented
>> database backend strikes me as a 12 week project in itself - yet this is
>> apparently just one line item in one part of your project proposal.
>>
>
> I think you may have misread that part of proposal. He's not proposing to
> write a database backend.  There is already one provided by the Google
> App Engine 
> SDK,
> so we're simply incorporating that into the configuration scripts (i.e.
> adding a settings_appengine.py that substitutes the DATABASE setting
> value).
>
>>
>> Lastly, your project proposal is very light on details. You're proposing
>> a lot of ideas, but you haven't really specified anything beyond "I'm going
>> to do it". Are there APIs that need to be specified? If, in the case of
>> something like a database backend, the APi is already specified, are there
>> going to be any complications in satisfying the API? We need a lot more
>> detail before we will be able to judge if you understand the project your
>> proposing, or if you are just proposing a bunch of ideas but haven't given
>> those ideas any more thought than "this sounds interesting"
>>
>
> I think the draft proposal was intended to get initial feedback and was
> intentially light on details. Colin and I can work on specifying more
> details on the actual deliverables within the next 

Re: Proposal for simplifying part of the GCBV API slightly.

[Tom Christie]

I've created ticket #20432  for 
this proposal.
I don't know if it needs to go to 'design decision needed', but if it gets 
approved I'll plan to work on it at the DjangoCon sprints, aiming for the 
1.6 alpha.

  Tom

On Monday, 22 April 2013 14:40:09 UTC+1, Andrew Ingram wrote:
>
> The original use case for pk_url_kwarg and slug_url_kwargs was something 
> like this:
>
> /(?P[\w-]*)/ - DetailView
> /(?P[\w-]*)/another-resource/ - Scoped ListView
> /(?P[\w-]*)/another-resource/(?P[\w-]*) - Scoped 
> DetailView
>
> In this case, the Scoped ListView and Scoped DetailView would both inherit 
> a mixin that overrides get_queryset(), and the Scope DetailView would just 
> set "slug_url_kwargs = 'another_slug'"
>
> I've used some variant of this pattern on almost every project I've been 
> involved with that utilises class-based views, including some frameworks, 
> so I don't think this edge case is quite as edgy as it might seem at first.
>
> However, I do agree that your simplification is an improvement. I've done 
> a lot with CBVs since I first suggested the URL kwarg overrides, and I 
> think it's better to have less configurable fields and focus instead on 
> having good entry points into customising the classes through method 
> overrides.
>
>
> Andy
>
>
>
> On 22 April 2013 13:33, Tom Christie wrote:
>
>> Hi Calvin,
>>
>> I can think of a few reasons.
>>> - you've changed models or fields internally through migrations, but 
>>> need to continue supporting old URLs.
>>> - you don't like the internal name to be exposed
>>> - you have different models but want to expose a consistent URL pattern.
>>
>>
>> Those attributes control the URL kwargs that are used in the regex, we're 
>> not talking about URL query parameters or anything else that's visible to 
>> the end-user.  Internal names aren't being exposed anywhere, and there'd be 
>> no issue with updating field names and continuing to support the URLs that 
>> reference them.
>>
>> Having said that, you're probably correct that I've overstated point (1) 
>> - There might be some circumstances where the developer would prefer to use 
>> 'slug' as the regex kwarg, but look up against a differently named model 
>> field.  I'd still think that there's a very strong argument to be made that 
>> we could consider that a corner case that requires overriding `get_object`, 
>> in exchange for having a simpler API for the standard case.
>>
>> There would of course be other alternatives such as using both 
>> `lookup_field` and `lookup_kwarg` with the later defaulting to the same as 
>> the former if unset, but I'm not wild about something like that given that 
>> the intention of this proposal is to try to slightly slim down an aspect of 
>> the API.
>>
>>
>> On Monday, 22 April 2013 12:37:32 UTC+1, Calvin Spealman wrote:
>>>
>>>
>>> On Apr 22, 2013 7:15 AM, "Tom Christie"  wrote:
>>> >
>>> > I'd be interested to know what you folks think of this proposal.
>>> >
>>> > SingleObjectMixin currently exposes these three attributes and one 
>>> method all dealing with queryset filter arguments...
>>> >
>>> > * pk_url_kwarg = 'pk'
>>> > * slug_field = 'slug'
>>> > * slug_url_kwarg = 'slug'
>>> > * get_slug_field()
>>> >
>>> > I was wondering if it would be worth considering simplifying the API 
>>> somewhat, by moving those three attributes, and that method, into a 
>>> PendingDeprecation state, and replacing their usage with a single attribute 
>>> instead, that is used both as the URL kwarg, and as the queryset filter.
>>> >
>>> > * lookup_field = 'pk'
>>> >
>>> > That'd (eventually) lead to a simpler get_object implementation 
>>> internally, and (immediately) present a slightly nicer, simpler API.
>>> >
>>> > It'd be marginally different in that slug based lookups would require 
>>> an explicit `lookup_field = 'slug'` to be added to the view,
>>> > and also in that it wouldn't handle the case of `slug_field` being set 
>>> to a different value from `slug_url_kwarg`.
>>> >
>>> > Personally I don't see the later being an issue as:
>>> >
>>> > 1. It's not clear to me why you'd ever *need* to use a URL kwarg 
>>> that's not the same as the filter arg.
>>>
>>> I can think of a few reasons.
>>> - you've changed models or fields internally through migrations, but 
>>> need to continue supporting old URLs.
>>> - you don't like the internal name to be exposed
>>> - you have different models but want to expose a consistent URL pattern. 
>>>
>>> > 2. If it's really something you need to do, then overriding get_object 
>>> is still really simple, as well as being nice and explicit...
>>> >
>>> > get_object(self, queryset):
>>> > if queryset is None:
>>> > queryset = self.get_queryset()
>>> > return get_object_or_404(queryset, ...) # whatever custom 
>>> lookup behavior you need.
>>> >
>>> > To me, the main trade-off seems to be - Is the resulting API enough of 

Re: Test failures under Oracle

[VernonCole]

How about creating django.contrib.db.backends for databases with a small 
maintainer "bus size" number?  Oracle and django-mssql could live there. 
 They would have less than full support, but still some level of official 
recognition?
--
Vernon Cole


On Wednesday, May 1, 2013 4:31:58 AM UTC-6, Florian Apolloner wrote:
>
> Hi,
>
> now that the 1.6 release plan is out, I'd like to push this topic again. 
> If you are using Oracle, now is the time to fix those bugs. Personally I am 
> toying with the idea of dropping Oracle support from core if we can't 
> ensure it's quality.
>
> Regards,
> Florian
>

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers" 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 http://groups.google.com/group/django-developers?hl=en.
For more options, visit https://groups.google.com/groups/opt_out.