I have seen gerrit in use with libreoffice, they have it setup to where you have build bot machines which can automatically pull a patch make a build and test the patch with the build to see if it builds successfully.
Also, with gerrit you dont need to assign reviewers people that have the ability and access can assign themselves to a particular patch to test. On Wed, Apr 17, 2013 at 3:55 PM, Jon Medhurst (Tixy) <t...@linaro.org>wrote: > On Wed, 2013-04-17 at 09:14 -0400, Christopher Covington wrote: > > Hi Jon, > > > > On 04/17/2013 06:29 AM, Jon Medhurst (Tixy) wrote: > > > On Wed, 2013-04-17 at 06:21 +0200, Jonathan Aquilina wrote: > > >> Doesnt email run the risk of a patch slipping through the cracks? > > > > > > And with gerrit the patch author needs to get an account enabled with > the > > > project, produce a git commit against the current tip, > > > > I can't recall ever seeing an upload refused because it wasn't against > the > > latest commit. What's the error message you get? > > Can't remember, sorry. > > > Or is it possible that you > > might be misremembering such an incident? > > > > > know who to pick as reviewers then rely on the people they pick to > > > actually review the patch > > > > I fail to see how emailing patches approaches this problem any > differently. > > It doesn't. > > > > then rebase and resubmit the patch because the tip has moved during the > > > review process > > > > Perhaps it is a small fault of the software that the configuration > doesn't > > default to an easier-going merge method such as cherry picking. It's > really > > easy to change, though. Admin->Projects->NAME->Project Options->Cherry > Pick. > > It seems like emailed patches have their fair share of merge conflicts. > > > > > and then have someone with commit rights accept it. > > > > I fail to see how emailing patches approaches this problem any > differently. > > It doesn't. > > > > And the web interface is horrible. > > > > What's your preferred intraline diff application? > > Not just diff, also how you comment on changes and reply to them. Email > is much nicer. > > > > You may have guessed I'm not a fan ;-) > > > > I don't necessarily think Linaro needs more Gerrit, but I would hate to > see > > misunderstandings about software that's been good to me go uncorrected. > > And I wasn't particularly trying to imply mailing lists solve problems > that Gerrit fails to, just that Gerrit adds hurdles and awkwardness - > especially for occasional contributors - and it seems to add little > benefit for that extra pain. You could say it keeps track of changes and > avoid them getting lost, but that only works if someone actually chases > up neglected changes. And mailing lists can use something like Patchwork > if they want similar tracking. > > I'm sure if I worked regularly on a project which used Gerrit then I > would get use to it and work out the tricks. > > Cheers > > -- > Tixy > > > Cheers, > > Christopher > > > > > -- Jonathan Aquilina
_______________________________________________ linaro-dev mailing list linaro-dev@lists.linaro.org http://lists.linaro.org/mailman/listinfo/linaro-dev
