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
