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 > <[email protected]<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 [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.
