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

[Russell Keith-Magee]

Hi Colin,

I've taken a look at your proposal, and I've got some concerns.

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.

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.

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"

Yours,
Russ Magee %-)

On Sunday, April 21, 2013, LittleQ@NCCU, Taiwan wrote:

> to django-developers:
>
> Sorry, I use Google Drive for proposing, and I original tend to copy
> it to here but found it will get in a mess.
>
> so I put my proposal here:
> http://goo.gl/xJyJ9
>
> My idea is to contribute to django-deployer and make some significant
> improvements for it.
> This proposal is still editing, but I pre-post it to prevent I'm thinking
> it in the wrong way.
>
> any questions or any advise are welcome, thank you, I'm really a big
> Django fan, and I hope I can make it better.
>
> cuz seems like there's no #django-dev, so feel free to add my XMPP
> directly: littleq0...@gmail.com  'littleq0...@gmail.com');>
>
> it's open for messaging anytime :D
>
>
> - Colin Su
>
>
>
>  --
> 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 'cvml',
> 'django-developers%2bunsubscr...@googlegroups.com');>.
> To post to this group, send email to 
> django-developers@googlegroups.com '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

[LittleQ@NCCU, Taiwan]

thank you, I forgot it  LOL

On Sunday, April 21, 2013 5:32:43 AM UTC+8, Florian Apolloner wrote:
>
> Hi,
>
> On Saturday, April 20, 2013 8:03:43 PM UTC+2, LittleQ@NCCU, Taiwan wrote:
>>
>> cuz seems like there's no #django-dev, so feel free to add my XMPP 
>> directly: littl...@gmail.com
>
>
> There is #django-dev (sic) on irc.freenode.net.
>
> 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.

Re: [GSoC 2013] Revamping validation functionality proposal

[Russell Keith-Magee]

Hi Christopher,

I'd like to echo Jacobs comments here. This is a strong proposal, and I can
see this being one that we'd support.

Jacob's feedback is also spot on; he's pretty much flagged the exact
concerns that I had when I read it.

I'd possibly add one additional point - the potential for confusion between
validation of the type you're describing, and "model validation". This
isn't a problem of your making - the ambiguity already exists in Django.
However, if we're adding API points on fields, which already support the
idea of "validators", we need to be careful we don't confuse issues more.
To that end, I'd be interested in seeing at least some initial thoughts on
how we can structure the API or change the naming so that this issue is
controlled.

On a practicality issue, I'd also like to see one more piece of detail in
your "why me" section. Since your from Poland, English is (I'm guessing) a
second language. Your proposal is very clear and shows you have good
communications skills. However, what we don't know is how long it took you
to write this proposal, and how comfortable you are working in English. If
you're not comfortable working in English in "real time" (e.g., on a spoken
phone call, or in IRC), then that will alter the way that you and your
mentor will interact - you may wish to only communicate via email, for
example; and this may slow down the rate of feedback that you can get from
your mentor.

I'd like to emphasise that I am *not* saying that we intend to give
preferential treatment to native English speakers. This is an issue of
finding me best possible mentor to match you with, and set expectations for
how quickly you will be able to make progress on your project.

Yours,
Russ Magee %-)

On Wednesday, April 17, 2013, Jacob Kaplan-Moss wrote:

> Hi Christopher -
>
> Thanks for the proposal, this is quite good. I really appreciate the
> detail; it's clear you've put a lot of thought into this. In general,
> I think this is a strong proposal and one I'd support. However, I do
> have some comments/feedback:
>
> 1. We've had some discussions about bringing django-secure into core
> as part of a more general "checkdeploy" command. The idea being
> something you can run shortly before deployment that'd check for all
> the stuff that django-secure checks for -- but also more (outdated
> dependencies, debug mode, exposed admin, etc). I think this dovetails
> nicely with your proposal: it seems that all these "checks"
> (validation, deployment, security) could use a single discovery and
> running mechanism. I'd love to see you think about modifying your
> proposal to include this sort of unification as well as the bringing
> of django-secure into core.
>
> 2. I think your proposal is a bit too big. I'd general prefer to see a
> less ambitious proposal with a high probability of success over a high
> risk/high reward. I'd like to see you drop the "django-updates" part
> of the proposal, and focus on validation and django-secure. If you end
> up with extra time, you can always use it to write more checks.
>
> 3. You've done a good job breaking up the first half of the project
> into one week chucks, which shows me you've thought carefully about
> the tasks and steps involved. However, when you get to the second
> half, you're a lot more vague. I'd like to see you think more
> carefully about your time during that second half.
>
> 4. Pet peeve alert: "documentation" shouldn't be an afterthought. I
> HATE seeing "week X: documentation" -- it implies that you're planning
> on *not* writing documentation as you go, but instead saving it for
> last. You've been around long enough to know that's not how we do
> things; documentation happens alongside code. You'd make me much
> happier if you updated your proposal to not imply that you'd leave
> documentation for later.
>
> Again, I want to stress that overall this is a really solid proposal;
> don't take my criticism *too* hard. I think it could be an excellent
> one, though, so I hope you'll take my suggestions into account. Good
> luck!
>
> Jacob
>
> On Tue, Apr 16, 2013 at 12:09 PM, Christopher Medrela
>  wrote:
> > I would like to participate in Google Summer of Code this year. I've
> written
> > proposal for "revamping validation functionality" idea. It's available
> as a
> > gist: https://gist.github.com/chrismedrela/82cbda8d2a78a280a129 .
> Below, I'm
> > pasting the proposal. Feel free to criticize it.
> >
> > Table of content
> >
> > 1. Abstract 1.1 Drawbacks of the existing framework 1.2 Goals 1.3
> Benefits
> > 2. The new framework 2.1 Overview 2.2 Advantages
> > 3. New features 3.1 django-secure 3.2 django-update
> > 4. Schedule and milestones
> > 5. Who am I?
> >
> > 1. Abstract
> >
> > 1.1 Drawbacks of the existing framework
> >
> > Django currently has a validation framework, but there are a lot of
> problems
> > with it. First of all, it is monolithic and developers cannot write
> custom
> > validation (see 

[GSoC 2013] Improved error reporting

[Damian Skrodzki]

*

Hi again.


Let’s try analyse the topic Improved error handling a little deeper.


I’ve found dozen opened issues related to bad error handling (these are 
rather *not* from Better Error Messages list). In general most of the bugs 
demand different approach for each one.

1. django admin

https://code.djangoproject.com/ticket/9373

https://code.djangoproject.com/ticket/14642 - maybe patch from last comment 
will be enough here

https://code.djangoproject.com/ticket/14408

https://code.djangoproject.com/ticket/10919 - probably limiting number of 
displaying modified objects would fix the problem

https://code.djangoproject.com/ticket/17417 -  it would worth to track and 
fix or raise suitable error


2. templates:

https://code.djangoproject.com/ticket/18995 

3. django.db

https://code.djangoproject.com/wiki/BetterErrorMessages?version=48#django.db- 
quite complex problem with high severity

https://code.djangoproject.com/ticket/13776 - [related to above] this could 
be fixed after some core dev will make decision how this code should behave 
(if it’s worth to pass this task from someone that will understand the 
problem to someone else)

4. various:

https://code.djangoproject.com/ticket/20250 - probably NoneType should be 
detected in django.db.models.sql.where.as_sql(self, qn, connection) already 
or even before. If we don’t want to prevent this value to be None or it’s 
not easily possible, the solution would be to catch None in last function 
raising some error. Error message could contain tip saying what might solve 
this problem.

https://code.djangoproject.com/ticket/16840 - need to raise an error for 
unexisting fields

https://code.djangoproject.com/ticket/19560 - consider if the warning 
should be changed into error here

https://code.djangoproject.com/ticket/15063 - I don’t fully understand the 
comment  2 but possibly I could fix it

5. group of tickets “approved” by core developers to produce more verbose 
message :

https://code.djangoproject.com/ticket/18959 

https://code.djangoproject.com/ticket/18866 

https://code.djangoproject.com/ticket/14343

https://code.djangoproject.com/ticket/12756

https://code.djangoproject.com/ticket/8760


Plan what to do:

Fixing most of errors should consist of following steps:

1. Analyse where and why error occurs.

2. Try to reproduce the bug (the best way would be creating a test if it’s 
not provided)

3. Now take one of actions:

a. Just fix error message

b. Consult issue with core developer and fix the problem raising error in 
more proper place or way

4. Create a fix for ticket and submit a patch to review 


Schedule


I thought about splitting the time for few-days intervals (it might be 
weeks) and assigning that bugs to them. The most important problems should 
be resolved first. As I said: If i take an easier set of issues - it should 
be possible to fix a dozen of them. If I’ll take more complex tickets that 
demand to take some decisions and medium reworks - I should take just few. 
Taking few sounds more reasonable for me.


Committing


I’m going to focus on a bunch of small problems so here I propose to do a 
commit (pull request) per problem. This would be easier to review by other 
developers and easier to link with problem. Additionally if some of the 
fixes will need additional changes, it won’t have any influence on the 
others.


Questions

1. Do you guys know some other “known” errors which are confusing to users?

2. Could this task include some things like:

https://code.djangoproject.com/ticket/18171 - some steps have been taken 
but it is still unfixed (and related to raised exception)

https://code.djangoproject.com/ticket/17015 - another issue that requires 
bigger patch and finally causes confusing error message.

or I rather shouldn’t touch errors like this?


What next?


I think finally I should take few or dozen of problems. My proposals here 
are weekly covering with your exemplary areas except admin area. Am I still 
on a correct track? There are few tickets related to django admin, maybe 
focusing on them will be a good direction. Although there are very few 
opened issues related to errors in templates - it would be hard to find 
them on myself. Also the group no5 (producing more verbose messages) is 
tempting to fix.

After I will choose issues to fix, I want to specify more precisely how to 
fix them.


PS. I still will be working on choosing issues to resolve/trying to know 
better presented already. I just wanted to share my first thoughts about 
this problem. Hopefully someone more experienced will direct me to a more 
appropriate way.

Damian

*

-- 
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 

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

[Florian Apolloner]

Hi,

On Saturday, April 20, 2013 8:03:43 PM UTC+2, LittleQ@NCCU, Taiwan wrote:
>
> cuz seems like there's no #django-dev, so feel free to add my XMPP 
> directly: littl...@gmail.com


There is #django-dev (sic) on irc.freenode.net.

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.

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

[LittleQ@NCCU, Taiwan]

to django-developers:

Sorry, I use Google Drive for proposing, and I original tend to copy 
it to here but found it will get in a mess.

so I put my proposal here: 
http://goo.gl/xJyJ9

My idea is to contribute to django-deployer and make some significant 
improvements for it.
This proposal is still editing, but I pre-post it to prevent I'm thinking 
it in the wrong way.

any questions or any advise are welcome, thank you, I'm really a big Django 
fan, and I hope I can make it better.

cuz seems like there's no #django-dev, so feel free to add my XMPP 
directly: littleq0...@gmail.com

it's open for messaging anytime :D


- Colin Su



-- 
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: The threat of the incompletely initialized django instance

[Pakal]

On Tuesday, April 16, 2013 8:41:26 AM UTC+2, ptone wrote:
>
>
>
> On Monday, April 15, 2013 4:51:24 AM UTC-7, Pakal wrote:
>>
>> (my previous answer disappeared in googlemail, I hope that one will 
>> survive the sending...)
>>
>> Thanks for the feedback,
>>
>> Preston, since ticket #3591 ticket and related discusions are partially 
>> obsolete compared to your current works, may I just know if your current 
>> evolution will automatically reproduce the auto init() of the devserver 
>> (i.e loading models from each installed app) ? Because being able to use 
>> the same several times, or to set its human name, are cool features, but 
>> imo the most critical part at the moment is that difference between dev and 
>> prod inits, which can bite hard the unwary djangoer.
>>
>>
> The approach would be more along the lines of defining a place that is 
> guaranteed to run at as distinct a time as possible in the startup process 
> - rather than trying to guarantee that all code gets imported in some 
> coherent way with the aim to trigger module level import code. The latter 
> is what we want to move away from.
>
> -Preston
>  
>

 OK, I don't understand though in which cases one wouldn't want all his 
INSTALLED_APPS models to be imported at startup  :?
Some for the "coherent way" - doesn't python's import mechanism already 
ensure that modules depending on each other import themselves in a proper 
order (except if cyclic imports ofc) ?

Regards,
Pascal


-- 
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.