----- Original Message -----
> From: "Ryan Harper" <ry...@us.ibm.com>
> To: "Alon Bar-Lev" <alo...@redhat.com>
> Cc: "Ryan Harper" <ry...@us.ibm.com>, "Ryan Harper" 
> <ry...@linux.vnet.ibm.com>, "Anthony Liguori"
> <aligu...@linux.vnet.ibm.com>, vdsm-devel@lists.fedorahosted.org, "Adam 
> Litke" <a...@us.ibm.com>
> Sent: Monday, September 10, 2012 9:41:14 PM
> Subject: Re: [vdsm] Patch review process
> 
> * Alon Bar-Lev <alo...@redhat.com> [2012-09-10 12:44]:
> > 
> > 
> > ----- Original Message -----
> > > From: "Ryan Harper" <ry...@us.ibm.com>
> > > To: "Alon Bar-Lev" <alo...@redhat.com>
> > > Cc: "Ryan Harper" <ry...@us.ibm.com>, "Ryan Harper"
> > > <ry...@linux.vnet.ibm.com>, "Anthony Liguori"
> > > <aligu...@linux.vnet.ibm.com>, vdsm-devel@lists.fedorahosted.org,
> > > "Adam Litke" <a...@us.ibm.com>
> > > Sent: Monday, September 10, 2012 8:33:53 PM
> > > Subject: Re: [vdsm] Patch review process
> > > 
> > > * Alon Bar-Lev <alo...@redhat.com> [2012-09-10 12:22]:
> > > > 
> > > > 
> > > > ----- Original Message -----
> > > > > From: "Ryan Harper" <ry...@us.ibm.com>
> > > > > To: "Adam Litke" <a...@us.ibm.com>
> > > > > Cc: "Ryan Harper" <ry...@linux.vnet.ibm.com>, "Anthony
> > > > > Liguori"
> > > > > <aligu...@linux.vnet.ibm.com>,
> > > > > vdsm-devel@lists.fedorahosted.org
> > > > > Sent: Monday, September 10, 2012 7:07:56 PM
> > > > > Subject: Re: [vdsm] Patch review process
> > > > > 
> > > > > * Adam Litke <a...@us.ibm.com> [2012-09-09 12:29]:
> > > > 
> > > > <snip>
> > > > 
> > > > > I'm certainly willing to review any patches that show up on
> > > > > the
> > > > > mailing
> > > > > list directly, so if folks want to submit patches first for
> > > > > review
> > > > > before pushing into gerrit; I'm quite happy with reviewing
> > > > > those.
> > > > 
> > > > Why won't you subscribe to vdsm-patches[1] and comment within
> > > > gerrit?
> > > 
> > > I am subscribed.  Commenting within gerrit is much slower for
> > > myself.
> > >  I'm
> > > always in my email client, so sending an email back involves far
> > > less
> > > work for myself and I don't have to write lots of words in a
> > > small
> > > text
> > > box without a proper text editor.
> > > 
> > > Gerrit comment workflow:
> > > 
> > > 1) follow link from vdsm-patches email to gerrit patch in browser
> > > 2) sign-in via openid
> > > 3) find which patch file I want to comment upon
> > > 4) select the line I want to comment upon to bring up text widget
> > > 5) write up comment in a browswer gui box without any support
> > > from
> > > text
> > > editor
> > > 6) repeat (3-5) if there are multiple files touched
> > > 7) go back to top
> > > 8) hit publish
> > > 
> > > 
> > > Email comment workflow after we know have inline patches.
> > > 
> > > 1) Reply to email
> > > 2) find lines in email for comments
> > > 3) write up responses in editor
> > > 4) close file and mail.
> > > 
> > > 
> > > > 
> > > > This method is superior as the past/present/future comments and
> > > > review
> > > 
> > > I disagree here.
> > > 
> > > > process is managed within productivity application, from birth
> > > > to
> > > > merge or death.
> > > 
> > > Much like an email thread with inline patches that's archived for
> > > everyone to read and review.
> > > 
> > > > 
> > > > Each comment within gerrit is going to the list as if sent
> > > > directly
> > > > to
> > > > the mailing list, so you can track the activity.
> > > 
> > > What's the point of going to the list if not to be able to
> > > respond to
> > > email?
> > 
> > You see the benefit of you as a reviewer, while there are other
> > reviewers (past and future, members and guests) and there is the
> > patch
> > owner.
> > 
> > While it may indeed be easier for you to "just" send a message, for
> > the other people who are involved in the process it may not be as
> > productive as managing the discussion within productivity
> > application
> > which supports the process quite well.
> 
> Sure; There is a fixed set of folks who already have been working
> with
> gerrit for some time and I'm sure are quite comfortable with the
> process.
> 
> Part of opening the community up is figuring out how best to attract
> and
> maintain additional developers.  When growing a community, reducing
> the
> barrier for entry is a must.
> 
> I'll posit that if contributions to gerrit-based communities require
> the
> additional openid, web-based commented/editing, some-what
> undocumented
> process for obtain review and approval then we're not going to see
> tremendous growth given the additional overhead of working with
> gerrit
> as a contributor.
> 
> Only recently did we get gerrit to push the code out after
> submission,
> meaning that if someone wanted to lurk and read the code, it was
> always
> through the web-based viewing; some comments showup on the page of
> the
> changeset, the other in-line comments are only available if you know
> which file the comment was made against.
> 
> All comments go to the vdsm-patches, but this is a one-way avenue;
> you
> don't see discussion happening in response; and if you want to reply,
> you have to sign-in to gerrit and hunt down the right file.
> 
> None of this is *bad*; it's just different.
> 
> Any one of these extra steps could be the excuse that keeps
> developers
> from participating.
> 
> 
> > 
> > It is not that gerrit is perfect, it is far from being perfect,
> > however has advantages over plain list.
> 
> I'd really like to hear what advantage gerrit provides over a simple
> mailing list with archives and threading for developers.  I'm
> struggling
> to find what problem it solves and how its use is helping grow the
> development community around vdsm, etc.
> 
> > 
> > You wrote initially that this discussion already took place, is
> > there
> > any new factor from previous discussion that should be taken into
> > consideration?
> 
> I don't recall exactly what you're referring to here, so point me at
> that comment/dicussion and I'll be happy to update/reply if things
> have
> changed since then.

I had this discussion in several other projects I was involved with.

I too like the email approach, and it was very hard for me to perform the 
gerrit magic.

At the end I reached the following conclusions:

1. If there is a small number of core developers (up to magic number of 5), 
gerrit is an overhead.

2. If the project is very modular (in a good sense of modularization), for each 
module goto (1).

3. Otherwise, discussions are just lost, creates a lot of noise for 
uninterested parties, and nobody can track of changes nor implications.

So regardless if gerrit if a great tool, and what is its advantages, we are not 
(1) nor (2)... so we have to use some tool to help us manage the process.

This is only my opinion.

Regards,
Alon.
_______________________________________________
vdsm-devel mailing list
vdsm-devel@lists.fedorahosted.org
https://lists.fedorahosted.org/mailman/listinfo/vdsm-devel

Reply via email to