On Fri, Aug 12, 2011 at 11:47 AM, Ahmed Radwan <[email protected]> wrote: > Thanks Arvind, > > I prefer RTC with timeout. If we decide on timeout, what is the suitable > timeout period and how can we manage it for different patches (some patches > may require more time than others for review)? Is the timeout measured from > review submission or from last activity on the review? Any ideas?
Good point Ahmed. I don't think there is any one scheme that will address all such concerns. Given that someone may view a change as trivial but it may be very complex for someone else, I think that the idea of a set timeout will not be fair in all cases. Another option to consider is to be like Hive project, where a committer's patch must be +1'd by another committer who actually commits it. For patches coming from non-committers, any committer who reviews it can commit it. Thanks, Arvind > > Best Regards > Ahmed > > On Fri, Aug 12, 2011 at 10:59 AM, Arvind Prabhakar <[email protected]>wrote: > >> Hi All, >> >> We are starting to see some traction in JIRA and patch activity. I >> believe now is a good time for us to put a formal policy in place that >> guides the overall review and commit process. Different projects have >> adopted different ways of addressing this, but at a high level there >> are two - Review-Then-Commit (RTC) style, and Commit-Then-Review >> (CTR). >> >> Lets discuss this to bring out various point of views and then do a >> formal vote on the candidate policy that is acceptable to the >> majority. >> >> My thoughts: I prefer RTC with timeout provisions. Specifically, I >> feel that every change must get reviewed and if the reviewers do not >> respond within a certain time, the change can be committed. >> >> Please share your thoughts, comments and concerns on this. >> >> Thanks, >> Arvind >> >
