Thanks for the answer. Just to be sure. As "Take the first project" you mean "2. Improved error reporting", correct? I wrote the whole post in reversed order which could confuse you.
On Monday, April 15, 2013 2:18:56 AM UTC+2, Russell Keith-Magee wrote: > > > > On Mon, Apr 15, 2013 at 7:51 AM, Damian Skrodzki > <dami...@gmail.com<javascript:> > > wrote: > >> Hi, >> >> After looking through proposed ideas for the current GSoC i found 2 >> issues related close to the code quality which I'm interested in. These are: >> >> >> 1. Best practices Updates >> 2. Improved error reporting >> >> Both tasks are a different but they are very closely related just to code >> quality which if very important especially in projects in size of Django >> ;). I will try to suggest that maybe merging them into one little bigger >> task would be better idea. I'll explainin characteristics of these. >> >> Take the second one as a first. This project will require trying to >> reproduce some bugs and fix some error handling in order to allow other >> developers to fix their bugs more easily. I think that trying to analyse >> code, predict all scenarios and write all expected messages seems like >> impossible task. It's better to fix tasks already reported by users. So >> here comes the list >> https://code.djangoproject.com/wiki/BetterErrorMessages. Unfortunately >> (or rather fortunately) I found many of the issues from "error handling" >> are outdated. On the other side it would be good to review that list and >> possibly fix that wrong messages but ... do you think that fixing few error >> handlers is enough for 2-month project? >> >> The first one will require to know best practices and then rewrite/update >> some code to follow them. I think that this could be continuous task, and >> the finish of this task if very blurred. Common sense tells me that we >> should start with refactoring from "the worst" code then current worst and >> keep doing until all project will be up to current best practices. When the >> big project is being developed constantly there always be some code that >> need refactoring. >> >> My idea would be to fix issues from bad "error messages list" which is >> definitely achievable and then start to refactoring few functionalities of >> Django that very needs it. To make the second part more achievable and >> precise, I should choose few particular functionalities the I'd like to >> take care of. This approach will allow to fix particular bugs reported by >> users. Moreover fixing simpler bugs is usually easier to start with >> project. Then having bigger knowledge i could refactor some code. >> >> >> Do you think that it's reachable to do that in described way? >> Or maybe better stick to the idea of taking just 1 of this projects and >> spend some more time on it? >> > > I think that if you do a detailed analysis, you'll find that *both* > projects could easily fill a full GSoC semester. > > Take the first project -- the wiki is there as a documented list of known > problems, not a comprehensive list of all problems. A comprehensive audit > of everywhere that Django internally catches and re-raises exceptions, and > how the stack track from those exceptions are exposed, would *easily* > consume 12 weeks. > > However, we're not going to accept a project proposal that has a schedule > of "audit code for 12 weeks". We're going to need you to do some initial > exploration and give us a more detailed list of the sorts of problems > you're going to look at. > > 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.
