[Opensource] Discussion: Walkthrough Committee

[Geeta Ramani]

+1 from me !! :)
Geeta

Lirian Ostrovica wrote:

> Bravo Mike,
>
> I think Expresso needs a slow down for a while, have a look back, and nicely pave
> the way till to the present.
> Making Expresso more friendly and more robust, will for sure result in a widen
> community.
> I personally would love to contribute, but it is almost impossible for now.
>
> Hope more people support the idea
>
> Lirian
>
> Michael Rimov wrote:
>
> > Hey All,
> >
> > Just a thought here....
> >
> > As Lirian and others have voiced, the Expresso code base could use
> > additional cleanup.  To be honest, I only see the possibility of this
> > happening by doing a series of code walk-throughs.  I, personally, believe
> > this is beneficial from a security standpoint as well since the OpenBSD has
> > proven time and time again that such practices significantly increase the
> > security of the software.
> >
> > So, if we did something like this, what would it look like?  How would
> > meetings happen?  How often, how much, etc?
> >
> > I suggest that something along the lines of a minimum of a 3 people meeting
> > that took place once a month and would entail a walk-though of probably
> > only one class at a time.  Depending on the size of the class the group
> > could decide to tackle more than one class as well.
> >
> > Pre-meeting tasks:
> > -Have somebody with Jalopy reformat the code for the class we're going to
> > look at.  This would provide a standard format that we could all agree on.
> >
> > -Somebody goes through the class and walks through the javadocs on the
> > class and adds what they do understand.  Leave '????' for javadocs on
> > undocumented classes/functions that don't make sense at a casual glance.
> >
> > Meeting Tasks:  Generalized walkthrough the code.  If nobody understands
> > the code being looked at, the goal of the walkthrough is to just understand
> > it at first and javadoc it.  Look for code cleanup.  Look for updating unit
> > tests, etc.
> >
> > Quorum:  As I said, I think 3 people groups are probably a good idea.  For
> > a distributed project and all our wild schedules, I don't really see being
> > able to corral more folks at once than that.  That doesn't mean only 3
> > people have to sign up for walkthroughs!  Depending on skill level with the
> > code, folks could 'tag along', others could form their own group... or
> > having additional people would help provide a 'pool' of people that could
> > meet at a particular time, thus helping to ensure the meetings happen :)
> >         Each group would have to have a committer on board.  [Major Contributor
> > and higher], and that person makes changes as suggested.  Anything that
> > isn't a 'quick fix' should be added to the Expresso task list for
> > fixing/refactoring for for the next release.
> >
> > How do we prioritize the classes to walk through?  There was an interesting
> > Dr. Dobbs article about somebody tracking down the classes that most likely
> > need walkthrough's simply by running standard code metrics against various
> > classes and computing a 'complexity' number.  Higher complixity classes
> > should be walked through first.  This should help yield the highest number
> > of bug fixes.
> >
> > How do we meet?  That depends... we could MSN or AIM... there's a few UNIX
> > folks out there that could donate the use of an IRC server.  Or if somebody
> > wanted to donate a 'conference call' system for use, that would be great
> > too.  This would be something to hash out.
> >
> > Anyway, I think things like this could greatly assist the Expresso code
> > base.  By only taking once class a month, we being a slow but steady effort
> > to clean things up, and by prioritizing our walkthroughs we could get the
> > worst offenders first.  Best of all, participants would get thorough
> > knowledge of one class at a time, and since.
> >
> > Reporting:  Probably it would be best if the findings of the walkthrough
> > were posted to the list.  We could agree on a general template so that
> > folks would only have to fill in the blanks.
> >
> > Implementation Timeline:  I would like to start this probably after the
> > release of 5.1 [or at least begin it well into the 'ea' schedule].
> >
> > So, the question is, what do you guys think of this, if we did this, who
> > would volunteer, and finally what could be done to make this more efficient?
> >
> > Feedback appreciated!
> >                                                         -Mike
> >
> > _______________________________________________
> > Opensource mailing list
> > Opensource at jcorporate.com
> > http://mail.jcorporate.com/mailman/listinfo/opensource
> > Archives: http://mail.jcorporate.com/pipermail/opensource/
>
> _______________________________________________
> Opensource mailing list
> Opensource at jcorporate.com
> http://mail.jcorporate.com/mailman/listinfo/opensource
> Archives: http://mail.jcorporate.com/pipermail/opensource/