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
