Re: [GSoC 2013] Improved error reporting

2013-04-27 Thread Damian Skrodzki 
Hi,

I think I've overestimated my abilities to writing that kind of proposal. 
I've tried being warned that it's "superhard" to find and analyse problem 
in that way. I've tried to analyse many issues related to django admin but 
without any general conclusions. Actually it demands to find some deeper 
problem which is hard without better knowing of the framework. I think I'm 
not able to find any particular problems that causes in reasonable amount 
of time in order to plan it.

Anyway, thank you for answers and support. I wish you to get many slots 
from Google on this year's GSoC.

Thanks,
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 http://groups.google.com/group/django-developers?hl=en.
For more options, visit https://groups.google.com/groups/opt_out.

Re: [GSoC 2013] Improved error reporting

2013-04-24 Thread Russell Keith-Magee 
On Thu, Apr 25, 2013 at 3:00 AM, Andrew Godwin  wrote:

> Hi Damian,
>
> We don't generally accept GSOC projects that are just a bit grab bag of
> problems - this is looking a little bit like that. I'd like to see a better
> breakdown of what kind of time each ticket would take and what your
> planning schedule would be - in particular, I'd like to make sure you have
> roughly 12 full weeks worth of work, as some of these tickets are quite
> easy to fix.
>
> It would also be nice to see you pick fewer issues but ones which were
> more difficult - a past security GSOC just focused on three or four main,
> difficult problems, and while not all got done, it developed in a
> reasonable way.
>

I agree with Andrew - we're not just looking for "fix a bunch of bugs" as a
GSoC project. Don't get me wrong - bug fixes are good, but you're in a
unique position of having a 12 week dedicated period for working on Django.
This is an opportunity to fix a problems at a deep level, not just skim
over a lot of surface.

However, your ticket triage isn't necessarily all a waste. An alternative
approach to your proposal would be to identify broad or systematic
problems, and use the tickets as exemplars of how that problem manifests.

An example of this (that doesn't come from GSoC) was Ben Firshman's
handling of syndication back in the days of Django 1.1. Ben identified that
there were a lot of open bugs in the syndication framework, and he analysed
the trends and causes of those bugs -- for the most part, IIRC, subtle
variations between Atom and RSS formats. He then identified that the
structure of the existing code was the cause of these problems, and
proposed an alternative structure that would address these problems - and
probably many more related problems.

So - instead of just proposing a bunch of tickets to fix, analyse why those
tickets exist. Are there recurring themes? Are we making the same mistake
in multiple parts of the codebase? Is it possible that the same problem is
being made somewhere else, but not being reported?

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.

Re: [GSoC 2013] Improved error reporting

2013-04-24 Thread Andrew Godwin 
Hi Damian,

We don't generally accept GSOC projects that are just a bit grab bag of
problems - this is looking a little bit like that. I'd like to see a better
breakdown of what kind of time each ticket would take and what your
planning schedule would be - in particular, I'd like to make sure you have
roughly 12 full weeks worth of work, as some of these tickets are quite
easy to fix.

It would also be nice to see you pick fewer issues but ones which were more
difficult - a past security GSOC just focused on three or four main,
difficult problems, and while not all got done, it developed in a
reasonable way.

Andrew


On Sat, Apr 20, 2013 at 11:00 PM, Damian Skrodzki wrote:

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

[GSoC 2013] Improved error reporting

2013-04-20 Thread 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