Enough of this coder-mance. Bang out the reviews already!!! :p
On Thu, Feb 14, 2013 at 9:19 PM, Prasanna Santhanam <t...@apache.org> wrote: > 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., >
