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 <bhais...@apache.org> wrote: > Hi, > > On Sun, Jun 8, 2014 at 11:19 PM, Mike Tutkowski < > mike.tutkow...@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 <bhais...@apache.org> wrote: > > > > > Hi Sheng, > > > > > > On Sun, Jun 8, 2014 at 8:57 AM, Sheng Yang <sh...@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 <bhais...@apache.org> > > > wrote: > > > > > > > > > Hi, > > > > > > > > > > On Sat, Jun 7, 2014 at 4:56 AM, Sheng Yang <sh...@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 <da...@gnsa.us> > > wrote: > > > > > > > > > > > > > On Tue, May 27, 2014 at 12:52 PM, Alex Huang < > > > alex.hu...@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.tutkow...@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.tutkow...@solidfire.com o: 303.746.7302 Advancing the way the world uses the cloud <http://solidfire.com/solution/overview/?video=play>*™*
