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 <[email protected]>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 > 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 [email protected]. > To post to this group, send email to [email protected]. > 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 [email protected]. To post to this group, send email to [email protected]. Visit this group at http://groups.google.com/group/django-developers?hl=en. For more options, visit https://groups.google.com/groups/opt_out.
