[Gdal-dev] GDAL Code Reviews - SoC and beyond

Chris Howell chowell at pyxisinnovation.com
Tue Jul 3 15:45:24 EDT 2007


Hi Frank,

It's probably a good idea once you initiate code reviews to keep them 
occurring regularly. I would suggest on every checkin. That's what we do 
in our office and it makes a huge difference on the quality of the code 
that is produced as well as a good learning opportunity for all.

Cheers
Chris

Tamas Szekeres wrote:
> Frank,
>
> Do you have some principles to follow in the course of the review from
> the aspect of the gdal project?
>
> Best regards,
>
> Tamas
>
>
>
> 2007/7/3, Frank Warmerdam <warmerdam at pobox.com>:
>> Folks,
>>
>> A decade ago when I worked in an office, we had developed a practice of
>> regular code reviews.  These were, I found, an excellent educational
>> tool for sharing best practice, and also helpful in identifying problems
>> in the reviewed code.
>>
>> As part of our commitment to our Summer of Code students, I'd like to
>> introduce this practice to GDAL.  While my initial aim is to give our
>> SoC students an opportunity to review other code, and to be reviewed,
>> I also am hopeful that we could continue the practice after this point.
>>
>> My concept of code reviews is that we would:
>>
>>   o Pick a particular module of code, hopefully around 1000 lines of
>>     code and not more than 2000.
>>
>>   o Get four reviewers to spend an hour each pre-reviewing the code, and
>>     making notes on points for discussion.
>>
>>   o Getting together in IRC, following along "line by line", likely 
>> using
>>     a line numbered view like:
>>      http://trac.osgeo.org/gdal/browser/trunk/gdal/port/cpl_minixml.cpp
>>
>>   o Spend about 1 hour reviewing in IRC, lead by a lead reviewer who
>>     keeps things moving.
>>
>>   o The Reviewee would be responsible for recording action items.
>>
>>   o The Reviewee would be expected to act on the suggestions, making the
>>     updated version available (along with the action items) within 
>> one week
>>     of the review for offline followup by reviewers.
>>
>> One challenge for code reviews is getting reviewers willing to commit 
>> the
>> two hours needed for the process.  I would suggest that we have our paid
>> maintainer (Mateusz) as one reviewer.  That for the SoC reviews we 
>> include
>> at on other SoC student as a reviewer, and that the mentors have to 
>> review
>> at least their own mentee.  That should give us 3 of 4 reviewers.  We 
>> will
>> call for volunteers for the fourth spot.
>>
>> Any opinions on this idea?  Are there any SoC students who can't 
>> can't access
>> IRC?
>>
>> Are there any SoC students who will have code available for review 
>> reasonably
>> soon?    I would like to suggest that we pick some other piece of code
>> initially for review.  As I would like to lead the first review, it 
>> should be
>> someone elses code.  I'll ask around a bit for some recently 
>> contributed code
>> by another author which can be the reviewed module.
>>
>> Best regards,
>> -- 
>> ---------------------------------------+-------------------------------------- 
>>
>> I set the clouds in motion - turn up   | Frank Warmerdam, 
>> warmerdam at pobox.com
>> light and sound - activate the windows | http://pobox.com/~warmerdam
>> and watch the world go round - Rush    | President OSGeo, 
>> http://osgeo.org
>>
>> _______________________________________________
>> Gdal-dev mailing list
>> Gdal-dev at lists.maptools.org
>> http://lists.maptools.org/mailman/listinfo/gdal-dev
>>
> _______________________________________________
> Gdal-dev mailing list
> Gdal-dev at lists.maptools.org
> http://lists.maptools.org/mailman/listinfo/gdal-dev
>
>



More information about the Gdal-dev mailing list