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 Sun, 08 Jun 2014 17:49:52 GMT
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?

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.

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>*™*

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