Kathey,

I totally agree with what you say here.

I think the 'patch submitted' is a step in the right direction, but I 
think it would be nice with some tool that could capture more of the 
workflow than Jira currently does.  I am not sure what is possible to 
arrange with Jira, but it would be nice if we were able to represent the 
"ping-pong game" between developers and reviewers.  Ideally, it would 
have been nice with more states like "patch reviewed, needs more work', 
"patch reviewed, ready for commit", a list of people that have reviewed 
the patch (maybe the states I mention should be for each reviewer), and 
the name of a committer that is planning to commit the patch when it is 
ready.  The ability to query over such information would make it a lot 
easier to find the issues that one needs to address.

I do not know Jira well enough to say what is possible to achieve, but I 
think if the community continues to grow, we will need to have tools 
that better support our process than we have today.

--
Øystein

Kathey Marsden wrote:
> There has been a lot of discussion of  the benefit from a 
> developer/reviewer/committer/product  perspective of  small,
> incremental, independent patches. They are  easy to back out or port if
> need be, easier to read and understand.   Developers are less likely to
> go far on  tangents that won't be accepted upon review.  All so much
> cleaner.    But there is a problem ....
> 
> The problem, I think,  is that developers without commit priveleges  get
> stuck and bogged down in the process...
> 1) Waiting for review.
> 2) Waiting   for a  committers attention to commit . (DERBY-85 for
> instance has waited for a very long time I think),
> 3)  Having  to sync up, rerun tests and resubmit patches for each piece
> or after conflicting changes go in.
> 
> This situation feeds upon itself. It can be hard to get on the train, so
> folks start bringing on extra baggage to avoid an extra trip, adding in
> this or that to just get it in.
> 
> The solution, I think, is  we need to grease the track for patches
> coming in.
> 
> 1)  Developers need to keep patches as small, incremental, and
> independent as possible so that they are easy to review and commit.
> 2) More non-committers need review and test changes and clearly
> indicate  that they feel they are ready to commit.
> 3) Committers need to be more responsive. We are getting more committers
> so this should help.
> 4) We need reporting on the aging of patches.  (We added that check box
> but I am still trying to figure out how to query on it)
> 
> I think creating an environment where patches are streamlined is key here.
> 
> Kathey
> 
> 
>