[Insight-developers] Gerrit Open Topics Noise

[Hans Johnson]

First:  I think that gerrit has the potential to be VERY beneficial to the
ITK development efforts.

However, it could easily become a deterrent to expanding the developer
community.

As a gatekeeper, it is of paramount important that it is 1) fair, 2) quick
for both rejections and acceptance, and 3) not a bottle neck holding up a
lot of development.

Here are some of my complaints/concerns about gerrit:
1. There are too many open topics that are
        a) Not actively being worked on
                 **  <http://review.source.kitware.com/77> BUG: 8524 Enabled
test of streamer with multidimensional splitter
<http://review.source.kitware.com/77>
                **  BUG: 8524 revised MultidimensionalSlitter algorithm to
work <http://review.source.kitware.com/78>
                **  Add initial support for C# wrapping
<http://review.source.kitware.com/89>
        b) In the wrong state (and I do not have access rights to change
them to abandoned or to fix them)
                **  Added documentation.
<http://review.source.kitware.com/75>  should be in merged
                **  BUG11297: Runtime warning in TransformMeshFilter
<http://review.source.kitware.com/113>  should be merged
        c) Claim to be ready to merge, but only through teleconference
backdoor information has this been waiting
                **  <http://review.source.kitware.com/76> Updated libtiff to
version 4.0beta6. <http://review.source.kitware.com/76>
    2.   Poluted by VTK and SimpleITK patches.  I only care about ITK work,
and the rest is noise that needs to be sifted through to get to the ITK
stuff.
                



=========================================
So here are some suggestions to prevent race condidtions in merging to clog
up the works of getting items through gerrit:

First:  We should all strive to get things out of Gerrit ASAP.  The minimum
reward for contributing, learing git/gerrit/ITK policies is that your work
is not held up in bureaucratic chaos.  Few thing can take the wind out of a
developers sails than 3 weeks waiting for a patch to be approved so that the
next dependant item can be worked on easily.

Second: Add a 4th ³On-Hold² category (Abandoned, Open, Merged, On-Hold), any
thing that is more than 3 weeks without activity gets pushed to the On-Hold
category.   In addition, sometimes a patch set is reviewed and approved by
several people, and there is a good reason to hold off merging for a bit
(i.e. coordination with other efforts, see tiff topic above).     The
³Owner² of a 3 week dormant topic needs to do one of the following:
    * Squeak louder and  drum up some more support
    * Abandon the work
    * Just go ahead and do the merge without explicit community approval

Third:  Allow selection of which projects you want to see.   I do not want
to see VTK topics.

Forth:  Build some sort of ³robot verifier² that auto commits a review for
Windows and Unix.  The review should contain a link to the dashboard results
of that build.    I find that the process of verifying that the build
succeeds and tests pass is very mechanical, but takes 1hour per topic to
test.  Additionally, I don¹t have the resources to test Windows builds.

Regards,
Hans

-- 
Hans J. Johnson, Ph.D.
Assistant Professor
200 Hawkins Drive
T205 BT, The University of Iowa
Iowa City, IA 52242
 
hans-johnson at uiowa.edu
PHONE: 319 353 8587




-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.itk.org/mailman/private/insight-developers/attachments/20101015/e14a0adc/attachment.htm>