[GSoC 2013] Improved error reporting
* 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 http://groups.google.com/group/djang
Re: [GSoC 2013] Improved error reporting
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 there are very few > ope
Re: [GSoC 2013] Improved error reporting
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
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.