All of lore.kernel.org
 help / color / mirror / Atom feed
From: Stewart Smith <stewart@linux.vnet.ibm.com>
To: Andrew Geissler <geissonator@gmail.com>,
	Dave Cobbley <david.j.cobbley@linux.intel.com>
Cc: OpenBMC Maillist <openbmc@lists.ozlabs.org>
Subject: Re: Gerrit alternatives
Date: Mon, 08 Jan 2018 10:19:24 +1100	[thread overview]
Message-ID: <87r2r1tfyb.fsf@linux.vnet.ibm.com> (raw)
In-Reply-To: <CALLMt=oqzKzhHYGhC02t6z7p1f+d+2oeq52HhPB6Wr0KWXtFGQ@mail.gmail.com>

Andrew Geissler <geissonator@gmail.com> writes:
> On Tue, Dec 19, 2017 at 7:26 PM, Dave Cobbley
> <david.j.cobbley@linux.intel.com> wrote:
>> Hey all,
>>
>> I am curious to see peoples input on using github as a code review mechanism
>> over gerrit. I see github/openbmc is already used quite well for sprint
>> planning and issue tracking, I feel like it would make a lot of sense to use
>> it for doing code reviews. As far as I understand it has a mechanism to
>> reproduce a similar paradigm to what we currently use today - as far as
>> Code-Review, Ok-To-Test, and Verified.
>>
>> I can see github has made several improvements over the last few years that
>> make it much more use-able to teams like us:
>>
>> - The ability to have approved maintainers for each specific repository with
>> https://github.com/blog/2392-introducing-code-owners
>>
>> - It has the ability to do a rebase-merge, keeping the git tree nice and
>> tidy.
>>
>> - A strong API to tie in additional tools that we may need.
>>
>>
>> Additionally, it will reduce the point of failure from also hosting gerrit.
>>
>> What are peoples thoughts on using this?
>
> As the guy who ended up having to maintain the current gerrit server,
> I'm all for an alternative :)
>
> But my problem is I really like gerrit.  github has def made some
> improvements to the review process though.  I see it has per-line
> comment ability now.
>
> I have a pull request out here for a non-gerrit openbmc repo if
> someone wants to look around -
> https://github.com/openbmc/openbmc-tools/pull/5
>
> One thing I really like is how gerrit allows you to iterate over a
> commit.  Someone makes some comments, you respond, upload a new patch
> set.  My understanding with github is you basically just keep adding
> on new commits in a pull request to address comments.  A feature I use
> all the time in gerrit is to look at the diff between a patch set I
> last reviewed and the latest one.  Also, I don't see an obvious
> mechanism in github to provide the different score levels
> (-2,-1,+1,+2)?  The gerrit dashboard is also really nice, providing me
> a nice easy way to see what's on my review list and what the current
> size and scores of those reviews are (for all repos in openbmc).

Basically all those features is why I like review via email and
patchwork. You can review/comment as much as you like, anywhere, easily,
even offline. As a maintiner, patchwork is invaluable, and passes the
"somebody else maintains it" test, while still actually being open.

> We also base a lot of our current CI infrastructure off of gerrit
> events.  I think most of it can be switched over to using github, but
> it's not inconsequential.

Some of the CI integration in patchwork needs a bit of work though. We need to bribe
the grads with something in order to get snowpatch fixed up :)

-- 
Stewart Smith
OPAL Architect, IBM.

      parent reply	other threads:[~2018-01-07 23:19 UTC|newest]

Thread overview: 6+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2017-12-20  1:26 Gerrit alternatives Dave Cobbley
2017-12-20 20:31 ` Andrew Geissler
2017-12-20 22:27   ` Dave Cobbley
2017-12-21  9:48     ` Paul Menzel
2017-12-21 14:36       ` Emily Shaffer
2018-01-07 23:19   ` Stewart Smith [this message]

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=87r2r1tfyb.fsf@linux.vnet.ibm.com \
    --to=stewart@linux.vnet.ibm.com \
    --cc=david.j.cobbley@linux.intel.com \
    --cc=geissonator@gmail.com \
    --cc=openbmc@lists.ozlabs.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.