On Fri, Feb 15, 2013 at 03:37:43AM +0530, Chiradeep Vittal wrote: > > > On 2/14/13 1:43 AM, "Prasanna Santhanam" <t...@apache.org> wrote: > > > > >Personally I'm okay with either tool. IMO the real issue is in people > >reviewing a patch within time for a release. On the review I've cited > >we've got a lot of things to learn from - > > > >a) timely response from blueprint (FS) owners and/or asking for time > >for a thorough review > >b) sign-off from multiple committers > >c) incremental patch sets > > > > I do feel that 'enough' committers problem highlighted by Pranav is a real > problem with the Gerrit workflow. But if the contributor asks for multiple > reviews then Gerrit is better than RB. In RB it is not clear when the > patch is ready for commit since it is not clear which of the previous > comments have been addressed.
True - for core components with single owners it might be hard but even a smoke test pass can be considered a review. Contributors can (and should?) review code, so their review counts as well. And that's been happening on RB which is a good sign. On the OS lists (*hates taking the same example*) committers are also chosen based on good code review. You don't have to push code necessarily. If there is a component you've been aiming to contribute to, one can review patches coming in that area. In summary while it may be true that gerrit outweighs the features when it comes to managing patch workflow with git - we will together as a community have to promote that good culture for stronger reviews. As Ahmad would put it - 'Nuff said, Let's do it! -- Prasanna.,
