cloudstack-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Mike Tutkowski <mike.tutkow...@solidfire.com>
Subject Re: [DISCUSS] Introducing Gerrit for quality? was: [PROPOSAL] Using continuous integration to maintain our code quality...
Date Mon, 09 Jun 2014 05:40:14 GMT
I think it would be nice, as well, if committers could bypass the process
for trivial changes and - as you say - areas they own or have expertise in,
but we should also have a somewhat clear divide between what qualifies to
bypass the process and what doesn't.

Let's see how much debate this thread generates and then we can talk about
voting on it a bit later - if it sounds like something people are
interested in.


On Sun, Jun 8, 2014 at 11:31 PM, Rohit Yadav <bhaisaab@apache.org> wrote:

> Hi,
>
> On Sun, Jun 8, 2014 at 11:19 PM, Mike Tutkowski <
> mike.tutkowski@solidfire.com> wrote:
>
> > I agree that we should be using a process tool like Gerrit or Phabricator
> > with CloudStack.
> >
> > Do you guys have a feel for how much work is involved if we decide to
> move
> > forward with using one of these tools?
> >
>
> IMO -- We should first have voting/decisions regarding this (heya PMC
> folks!), the tools and timelines. Next, the ASF infra team can be requested
> provision servers to setup Gerrit or Phabricator or anything else for that
> matter (with a CI if we want unit testing automation for each commit or
> periodically), and have CloudStack repos linked to it. After that we'll
> need to setup wikis and documentation regarding the new process and educate
> and influence everyone to start using it.
>
>
> > I'm curious to see how disruptive it will be to our release schedule (if
> at
> > all), should we proceed forward with Gerrit or Phabricator.
> >
>
> We can start with master and leave 4.4 and other branches. It should not
> hinder our release schedules.
>
> IMO we should allow committers to bypass code reviews for trivial changes
> and things that they own or have expertise of, to cut time and to not force
> process on people.
>
> Regards.
>
>
> >
> > Thanks!
> >
> >
> > On Sun, Jun 8, 2014 at 2:31 AM, Rohit Yadav <bhaisaab@apache.org> wrote:
> >
> > > Hi Sheng,
> > >
> > > On Sun, Jun 8, 2014 at 8:57 AM, Sheng Yang <sheng@yasker.org> wrote:
> > >
> > > > Hi Rohit,
> > > >
> > > > Well, I don't quite understand why gerrit is "old". Google has a team
> > > > actively working on it and the release of new version seems pretty
> fast
> > > to
> > > > me(https://code.google.com/p/gerrit/, latest release at
> June(2.9-rc2)
> > > and
> > > > May(2.8.5) this year). Since Google, SAP and OpenStack are using it I
> > > don't
> > > > think quality or functionality would be an issue generally. The most
> > > > enticing feature of gerrit for me is itself is the repo, and you
> cannot
> > > go
> > > > around the gerrit to check in without proper process in any case.
> > > >
> > > > I didn't look into deep about Phabricator currently but I don't want
> to
> > > > bring "A is better than B" discussion at this moment. I think that
> can
> > be
> > > > up to evaluation after we decided that test and review need to be
> > > enforced
> > > > through automation process.
> > >
> > >
> > > +1 can we have a PMC member to lead this effort and start
> > discussion/voting
> > > on having a test/review process?
> > >
> > >
> > > > Which tool is best for that purpose can be up
> > > > to discuss.
> > > >
> > >
> > > Sure. This thread started like "Let's start using Gerrit", on the face
> > > value I thought it's like we've already considered which tool to use
> and
> > we
> > > just want to start with setup/adoption process.
> > >
> > > By "old", I was implying low commit/development activity and
> > > technical/design debt it carries. Since I've used both of them (and
> > > Gitlab/Github) for writing real software, I'll list couple of specific
> > pain
> > > points wrt code reviewing, but before that I would like everyone to try
> > > both of them before making mind;
> > >
> > > Try Gerrit2 with your github repo: http://gerrithub.io
> > > Explore Phabricator: https://secure.phabricator.com
> > >
> > > You may google to find reviews on both, I was going to write a
> > comparative
> > > summary but this quora answer summarizes my pain points:
> > > http://qr.ae/sudCG
> > >
> > > Phabricator is more like a swiss knife but has three great tools inside
> > it
> > > IMO useful for ACS like Differential (code reviews, pre-commit), Audit
> > > (review, post-commit), Arcanist (command line tool),  Herald (alarms on
> > > certain parts of code, such as db files etc.). Unnecessary features can
> > be
> > > turned off.
> > >
> > > Arcanist is awesome, it speeds up the workflow of sending patch,
> testing
> > > it, merging it etc. The whole patch can be viewed in one tab, in-line
> > > comments work, the UI is much better, works better with
> JIRA/Confluence,
> > > they are opensource too and have a more active development community.
> > >
> > > Companies using Phabricator: http://leanstack.io/phabricator
> > > Code reviewing compared: http://leanstack.io/code-review
> > >
> > > I'm sharing my opinion just to help us consider best tool for the job
> and
> > > adopt it in future.
> > >
> > > Regards.
> > >
> > >
> > > > --Sheng
> > > >
> > > >
> > > > On Fri, Jun 6, 2014 at 10:48 PM, Rohit Yadav <bhaisaab@apache.org>
> > > wrote:
> > > >
> > > > > Hi,
> > > > >
> > > > > On Sat, Jun 7, 2014 at 4:56 AM, Sheng Yang <sheng@yasker.org>
> wrote:
> > > > >
> > > > > > Hi all,
> > > > > >
> > > > > > Seems it's a good timing to bring back the discussion about
the
> > > gerrit.
> > > > > >
> > > > > > We want to do CI, and improve our code quality. One obvious
way
> of
> > > > doing
> > > > > > and reduce the workload of devs is introduce a tool to enforce
> the
> > > > > process.
> > > > > >
> > > > > > I've checked out quite a few projects using gerrit, which would
> > force
> > > > you
> > > > > > to ask for review, and validation before the code can be
> committed
> > to
> > > > the
> > > > > > repo. Looks it's really a easier way for devs according what
I've
> > > > heard.
> > > > > >
> > > > > > Even our competitor laid out a very detail workflow based on
the
> > use
> > > of
> > > > > > gerrit( https://wiki.openstack.org/wiki/Gerrit_Workflow ). I
> guess
> > > it
> > > > > can
> > > > > > make a good reference.
> > > > > >
> > > > >
> > > > > I've used gerrit before, it's old and has its own pain points. I
> > > suppose
> > > > we
> > > > > need an on-premise solution that ASF infra folks can help setup for
> > > > > projects such as CloudStack.
> > > > >
> > > > > So, can we consider other/better opensource alternatives such as
> > > > > Phabricator (phabricator.org), I've used it before and it's great.
> > It
> > > > > comes
> > > > > with a command line tool and a web ui for all tasks and comes with
> > > > > following stuff;
> > > > >
> > > > > - a command line tool (called archanist) which allows you to
> > > > > review/test/merge patches and while committing it hooks up linters
> > and
> > > > unit
> > > > > testing
> > > > > - it allows you to audit patches i.e. review commits already pushed
> > on
> > > a
> > > > > branch
> > > > > - it has alarms (herald) which can trigger on bunch of rules and
> > alert
> > > us
> > > > > via email, for example if someone changes database files we can put
> > an
> > > > > alarm on set of files to get alert emails
> > > > > - people who have used Github reviewing would have less time
> learning
> > > to
> > > > > use it
> > > > > - works with git (hg, svn etc.)
> > > > > - high quality software with many awards and used/maintained by
> tons
> > of
> > > > > companies such as Facebook, Dropbox etc.
> > > > >
> > > > > Before we start with the actionable items, please just explore it
> > here
> > > > > http://phabricator.org/tour
> > > > >
> > > > > Regards.
> > > > >
> > > > >
> > > > > > Well, gerrit has been brought up a few times before. And now
the
> > new
> > > > > > process we want to enforce just fits what gerrit(or other
> > automation
> > > > > > review/test/commit software) is for.
> > > > > >
> > > > > > Maybe it's the time for us to review the possibility of using
a
> > tool
> > > to
> > > > > > enforce our commits and improve our code quality(as well as
> > transfer
> > > > > > knowledge) again?
> > > > > >
> > > > > > --Sheng
> > > > > >
> > > > > >
> > > > > > On Tue, May 27, 2014 at 8:28 PM, David Nalley <david@gnsa.us>
> > wrote:
> > > > > >
> > > > > > > On Tue, May 27, 2014 at 12:52 PM, Alex Huang <
> > > Alex.Huang@citrix.com>
> > > > > > > wrote:
> > > > > > > >> Like Chip, I am very concerned with this being
dependent on
> a
> > > > single
> > > > > > > >> company, even if its the company that employs
me. It isn't
> > > > > > sustainable,
> > > > > > > it
> > > > > > > >> excludes others from contributing, and makes the
project
> less
> > > > > > > independent
> > > > > > > >> because it depends on a single company's infrastructure.
> > > > > > > >
> > > > > > > > Agreed there.
> > > > > > > >
> > > > > > > >>
> > > > > > > >> I'm also unclear on the answer to the question
in the FAQ.
> The
> > > > first
> > > > > > > time I
> > > > > > > >> read it, I got the impression that you were happy
to bring
> it
> > up
> > > > on
> > > > > > > hardware
> > > > > > > >> at the ASF if the ASF wanted to own it. The second
time I
> read
> > > it
> > > > I
> > > > > > > wondered
> > > > > > > >> if you meant that Citrix was going to attempt
to donate
> > > hardware.
> > > > > > > >>
> > > > > > > > Sorry if I did not make that clear.  I meant the scripts/code
> > > that
> > > > we
> > > > > > > wrote are checked in publicly and we're willing to help
set it
> up
> > > if
> > > > > ASF
> > > > > > > provided the hardware.  I have not approach Citrix on donating
> > the
> > > > > actual
> > > > > > > hardware.  Although I can approach them if it speeds up
the
> > > adoption
> > > > > > > process.
> > > > > > > >
> > > > > > > >> Finally - what do you think you need from ASF
infra to make
> > this
> > > > > > happen?
> > > > > > > >>
> > > > > > > >
> > > > > > > > It's currently about 10 servers with two networks.
 One
> network
> > > is
> > > > > > > static with IPMI to PXE boot the machines.  The other network
> is
> > > the
> > > > > > actual
> > > > > > > data network that CloudStack uses.  That's actually just
enough
> > for
> > > > > > > XenServer and KVM.  In order to accommodate for HyperV,
Bare
> > Metal,
> > > > > LXC,
> > > > > > > (which we do not have any test cases in the automation
suits
> > > > currently)
> > > > > > we
> > > > > > > will need even more machines.  We might be able to use
nested
> > > > > > > virtualization for the hypervisors to maintain server count
at
> > ten
> > > > or a
> > > > > > > little more than ten but we haven't explore that yet.
> > > > > > > >
> > > > > > > > The CI process is up and running on those machines
but
> because
> > we
> > > > > > didn't
> > > > > > > have CI running on master before, automation tests that
were
> > > passing
> > > > > for
> > > > > > > 4.3 are now broken again on 4.4. and master.  I think Sudha
> > already
> > > > > > > reported on the list that QA is busy trying to fix all
the
> > > automation
> > > > > > tests
> > > > > > > to bring CI on 4.4-forward and master back to 100% pass
rate.
> > > > > > >  Unfortunately, it's been delaying our effort to put this
out
> in
> > > the
> > > > > > public
> > > > > > > and let the community try this themselves.
> > > > > > > >
> > > > > > > > --Alex
> > > > > > > >
> > > > > > >
> > > > > > > So the board just approved a 3 month budget, but the new
board
> > will
> > > > > > > have to take up the remainder of the FY budget shortly
after
> > coming
> > > > > > > into office. Perhaps worth coming up with an estimate of
what
> > this
> > > > > > > will cost/need and getting it to president@ before that
new
> > budget
> > > > is
> > > > > > > taken up.
> > > > > > >
> > > > > > > --David
> > > > > > >
> > > > > >
> > > > >
> > > >
> > >
> >
> >
> >
> > --
> > *Mike Tutkowski*
> > *Senior CloudStack Developer, SolidFire Inc.*
> > e: mike.tutkowski@solidfire.com
> > o: 303.746.7302
> > Advancing the way the world uses the cloud
> > <http://solidfire.com/solution/overview/?video=play>*(tm)*
> >
>



-- 
*Mike Tutkowski*
*Senior CloudStack Developer, SolidFire Inc.*
e: mike.tutkowski@solidfire.com
o: 303.746.7302
Advancing the way the world uses the cloud
<http://solidfire.com/solution/overview/?video=play>*™*

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message