> -----Original Message----- > From: Sebastien Goasguen [mailto:run...@gmail.com] > Sent: Wednesday, August 20, 2014 1:47 PM > To: dev@cloudstack.apache.org > Subject: Re: [VOTE] Adapting git workflow for release branches > > > On Aug 20, 2014, at 4:33 PM, Edison Su <edison...@citrix.com> wrote: > > > > > > >> -----Original Message----- > >> From: Rohit Yadav [mailto:rohit.ya...@shapeblue.com] > >> Sent: Wednesday, August 20, 2014 1:17 PM > >> To: dev@cloudstack.apache.org > >> Subject: Re: [VOTE] Adapting git workflow for release branches > >> > >> > >> On 20-Aug-2014, at 9:55 pm, Edison Su <edison...@citrix.com> wrote: > >>> Maybe I need to reiterate why I reject the proposal for now, as I am > >>> the > >> only person vote -1(binding). > >>> I think we all understand the pain as a release manager, even right > >>> after 4.2 release, I asked community to think about how We gonna fix > >>> the > >> release procedure(http://markmail.org/message/3bptkm2xyrai6i7m), no > >> much response at that time. > >>> But the situation is much better now, as more and more people are > >>> trying > >> to solve the problem, instead of staying on the status quo. > >>> To me, the highest priority issue we need to solve is the CI, even a > >>> simple > >> CI against simulator, will catch a lot of regressions in management > >> server code. > >>> The second priority, is code review. > >>> The git flow co-relates to how we gonna solve above two issues. I > >>> think that's the different opinions we have today, and I already > >>> made the point that If we choose different ways to solve the above > >>> two issues, we may choose different git flow: > >>> http://markmail.org/message/hyk54z7imn5gyqkn > >>> So can't we just put our efforts to solve the big problems at first, > >>> instead of > >> debating on the small things forever? > >> > >> I surrender (and this proposal), but I would still like to see > >> something actionable on the "big" problems from your side like why > >> don't you start a proposal/discussion around it? Let's solve the biggies > >> first. > > > > There are several proposals from Citrix: > > http://markmail.org/thread/c4pded5i3r22keqw > > http://markmail.org/thread/xoyjw2sduenlytwm > > Edison, Citrix can't make proposals. Individuals do.. Sorry, what I am trying to say is "from people, who happen to be employee from Citrix".
> I know Citrix has an internal BVT/CI whatever you want to call it system, but > until it is live for the whole community I don't think there is any point of > discussing it. > > There is hardware being donated (which people on this list may not be aware > off), but it is not available yet, nor do we know how this hardware will be > managed. > So right now the only apache infra we have to do CI is the current jenkins > setup and things like TravisCI which I have mentioned before. > > In any case, the threads you mention did not reach consensus or led to a > vote thread. The way forward is to keep working on those threads or start a > VOTE thread. > > I am just wondering what we will VOTE on in terms of CI, since there is no > infra to do it yet and nobody seems to be owning this (or maybe I missed > some threads). Ok, I got it. So right now, we don't have problem about need to have CI or not, It's about how will gonna do it, right? The options we have today: 1.TravisCi, 2. the CI donated from Citrix(I heard of that the donated hardware is delayed, I mistakenly thought the hardware is already donated), 3. any other hardware( I am working on a machine created on DigitalOcean, $80/month, 8G memory, 4 core cpus, SSD, I want to donate it as CI machine personally, if there is no other good solution) Any other options? > > -sebastien > > > Citrix also donates real hardware for CI. > > We don't lack of proposals to solve these issues, it's community has > > different opinions On how to solve these issues, or don't solve these issues > at all. > > Going forward, we need to have consensus on we have to solve these > > issues before we start another release: > > http://markmail.org/thread/ofalvk4uhejtffpg > > > >> > >> Edison the things I was trying to bring IMO won't conflict with any > >> future CI/code review process that we may adopt, they focus on how we > >> can improve community participation and do (multiple) releases & > >> commit maintenance across branches. > >> > >> Regards, > >> Rohit Yadav > >> Software Architect, ShapeBlue > >> M. +41 779015219 | rohit.ya...@shapeblue.com > >> Blog: bhaisaab.org | Twitter: @_bhaisaab > >> > >> > >> > >> Find out more about ShapeBlue and our range of CloudStack related > >> services > >> > >> IaaS Cloud Design & Build<http://shapeblue.com/iaas-cloud-design-and- > >> build//> > >> CSForge - rapid IaaS deployment > >> framework<http://shapeblue.com/csforge/> > >> CloudStack Consulting<http://shapeblue.com/cloudstack-consultancy/> > >> CloudStack Infrastructure Support<http://shapeblue.com/cloudstack- > >> infrastructure-support/> > >> CloudStack Bootcamp Training > Courses<http://shapeblue.com/cloudstack- > >> training/> > >> > >> This email and any attachments to it may be confidential and are > >> intended solely for the use of the individual to whom it is > >> addressed. Any views or opinions expressed are solely those of the > >> author and do not necessarily represent those of Shape Blue Ltd or > >> related companies. If you are not the intended recipient of this > >> email, you must neither take any action based upon its contents, nor > >> copy or show it to anyone. Please contact the sender if you believe > >> you have received this email in error. Shape Blue Ltd is a company > >> incorporated in England & Wales. ShapeBlue Services India LLP is a > >> company incorporated in India and is operated under license from > >> Shape Blue Ltd. Shape Blue Brasil Consultoria Ltda is a company > >> incorporated in Brasil and is operated under license from Shape Blue > >> Ltd. ShapeBlue SA Pty Ltd is a company registered by The Republic of > South Africa and is traded under license from Shape Blue Ltd. ShapeBlue is a > registered trademark.
