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