Thanks for starting this discussion Alan! Something we might try is having "patch available" issues mailed to the list each day, and working towards managing the list to 0, by either committing or bouncing back to "open" if it need more work. I personally subscribe to that jira query and find it quite useful.
Maybe this is obvious to those with more open source experience, but I'm learning each "external" patch bears some amount of risk, since how it fits into the contributors overall goals may not have been communicated well. We could use "epic stories" or design docs to communicate high-level goals so the purpose of external patches is more clear. For example, I'm super focused on thrift support which explains a lot of our patches, but wouldn't be clear to a reviewer looking at them in isolation. This could help reduce risk of accepting patches since it would be clear how they fit into bigger-picture goals. Just tossing some ideas out, curious what others think. --Travis On Aug 31, 2012, at 4:04 PM, Alan Gates <[email protected]> wrote: > It is pretty clear that we, the HCatalog committers, are not doing a good > enough job of reviewing patches in a timely manner. Many committers or other > contributors are posting patches only to have them wait for a couple of weeks > before someone reviews them. Then when any requested changes have been made > it is another couple of weeks before a +1 and the code can be checked in. > This is bad for a number of reasons. It makes it hard for committers to move > forward with what they are working on. It does not encourage others to join > our community, as we appear to be spurning their contributions. And it means > that users do not get access to bug fixes and new features as soon as they > could. > > We as a community need to figure out how we want to resolve this. > Suggestions? > > Alan.
