> -Original Message-
> From: Erik Weber [mailto:terbol...@gmail.com]
> Sent: Wednesday, August 20, 2014 12:25 PM
> To: dev
> Subject: Re: [PROPOSAL] Using continuous integration to maintain our code
> quality...
>
> On Wed, May 7, 2014 at 2:03 AM, Alex Huang
Hi,
On 8/20/14 12:24 PM, "Erik Weber" wrote:
>They both had fundamental flaws, where the one was
>practically useless for a week or so, and the other had major issues with
>KVM, and if the BVT doesn't encounter those because it's using the
>simulator I see it as a burden rather than a gift, sin
On Wed, May 7, 2014 at 2:03 AM, Alex Huang wrote:
> Hi All,
>
> This is something I brought up a long time ago but really didn't have the
> resources to get it all up and running until now. Throughout the past
> year, Edison, Prasanna, Amogh, Bharat, Koushik, Talluri, and others have
> been chip
Bumping up this thread since another one seems to be starting over CI
Amogh
On 5/27/14 8:28 PM, "David Nalley" wrote:
>On Tue, May 27, 2014 at 12:52 PM, Alex Huang
>wrote:
>>> Like Chip, I am very concerned with this being dependent on a single
>>> company, even if its the company that employs
> still has to do the work...
>
> --
> Stephen Turner
>
>
> -Original Message-
> From: Trippie [mailto:trip...@gmail.com] On Behalf Of Hugo Trippaers
> Sent: 11 June 2014 10:52
> To: dev@cloudstack.apache.org
> Subject: Re: [DISCUSS] Introducing Gerrit for
ginal Message-
From: Trippie [mailto:trip...@gmail.com] On Behalf Of Hugo Trippaers
Sent: 11 June 2014 10:52
To: dev@cloudstack.apache.org
Subject: Re: [DISCUSS] Introducing Gerrit for quality? was: [PROPOSAL] Using
continuous integration to maintain our code quality...
Sheng,
In the end we
Sheng,
In the end we both want the same thing, which is a higher quality codebase.
However i find the technology first approach the wrong approach in this case.
Of course supporting tools are needed to make the process more efficient. My
main worry here is that the “experts” are not reviewing c
Hi Hugo,
The main point I want to bring up an automation tool here is, enforce
mandatory review process and test(regression test probably) to happen
before commit. That would slow down the process of course, but it should
greatly help on code quality.
Even committers would make mistakes from time
Hey,
I’m all for automated solutions. I’m a happy gerrit user on some other projects
and quite fond of working with Github pull requests as well. However there is
one important point that makes working with those tools work and that is a
willingness by the committers to review requests. Both sy
+1 for github pull requests. They are much better and cleaner than review board.
~Rajani
On 09-Jun-2014, at 9:17 pm, David Nalley mailto:da...@gnsa.us>>
wrote:
On Fri, Jun 6, 2014 at 7:26 PM, Sheng Yang
mailto:sh...@yasker.org>> wrote:
Hi all,
Seems it's a good timing to bring back the disc
On Mon, Jun 9, 2014 at 3:14 PM, Rohit Yadav wrote:
> On Mon, Jun 9, 2014 at 11:32 PM, sebgoa wrote:
>
>>
>> On Jun 9, 2014, at 7:13 PM, David Nalley wrote:
>>
>> > On Mon, Jun 9, 2014 at 11:47 AM, David Nalley wrote:
>> >> On Fri, Jun 6, 2014 at 7:26 PM, Sheng Yang wrote:
>> >>> Hi all,
>> >>>
That sounds good to me, as well.
On Mon, Jun 9, 2014 at 1:14 PM, Rohit Yadav wrote:
> On Mon, Jun 9, 2014 at 11:32 PM, sebgoa wrote:
>
> >
> > On Jun 9, 2014, at 7:13 PM, David Nalley wrote:
> >
> > > On Mon, Jun 9, 2014 at 11:47 AM, David Nalley wrote:
> > >> On Fri, Jun 6, 2014 at 7:26 PM,
On Mon, Jun 9, 2014 at 11:32 PM, sebgoa wrote:
>
> On Jun 9, 2014, at 7:13 PM, David Nalley wrote:
>
> > On Mon, Jun 9, 2014 at 11:47 AM, David Nalley wrote:
> >> On Fri, Jun 6, 2014 at 7:26 PM, Sheng Yang wrote:
> >>> Hi all,
> >>>
> >>> Seems it's a good timing to bring back the discussion a
On Jun 9, 2014, at 7:13 PM, David Nalley wrote:
> On Mon, Jun 9, 2014 at 11:47 AM, David Nalley wrote:
>> On Fri, Jun 6, 2014 at 7:26 PM, Sheng Yang 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 co
On Mon, Jun 9, 2014 at 11:47 AM, David Nalley wrote:
> On Fri, Jun 6, 2014 at 7:26 PM, Sheng Yang 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 worklo
I like github pull request as well from past usage, it is very convenient
for developers and reviewers to perform their tasks, compared to our
current RB. Also agree with David, the pre-requisite for this enforcement
is that we should have CI in place to make this happen.
Thanks
-min
On 6/9/14 8:
On Fri, Jun 6, 2014 at 7:26 PM, Sheng Yang 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'v
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
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 thes
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
Hi Sheng,
On Sun, Jun 8, 2014 at 8:57 AM, Sheng Yang 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) a
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
+1
-Original Message-
From: John Kinsella [mailto:j...@stratosec.co]
Sent: Friday, June 06, 2014 7:28 PM
To: dev@cloudstack.apache.org
Subject: Re: [DISCUSS] Introducing Gerrit for quality? was: [PROPOSAL] Using
continuous integration to maintain our code quality...
+1 seems like a
Hi,
On Sat, Jun 7, 2014 at 4:56 AM, Sheng Yang 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.
>
+1 seems like a good idea.
On Jun 6, 2014, at 4:26 PM, Sheng Yang
mailto: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 introdu
+ 1 to gerrit
-Original Message-
From: Sheng Yang [mailto:sh...@yasker.org]
Sent: Friday, June 06, 2014 4:27 PM
To:
Subject: [DISCUSS] Introducing Gerrit for quality? was: [PROPOSAL] Using
continuous integration to maintain our code quality...
Hi all,
Seems it's a good timi
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 for
On Tue, May 27, 2014 at 12:52 PM, Alex Huang 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 depen
> 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.
> @Chip and @Hugo
>
>> Correct, and my statement stands. I'm -1 on any policy within the project
>> that enforces the use of a single company's resources if they are only
>> controlled by that company. Let's see how we can move this to the ASF (and
>> tweak / tune based on a better understanding
Sorry for the late replies on this folks. I've been away for my $dayjob at
Citrix. Let me try to see if I can make clear what I see as
objections/questions/understandings and address them one by one. If I got them
wrong, let me know and please clarify what you're asking.
@Sebastien
> Why don
On Mon, May 26, 2014 at 3:12 PM, Animesh Chaturvedi
wrote:
>
>>
>> I'll also state for the record, that I will -1 any decision that leads us to
>> depend on a single company's infrastructure as a project level policy. That
>> said, having it available from Citrix for use is a great thing for that
>
> I'll also state for the record, that I will -1 any decision that leads us to
> depend on a single company's infrastructure as a project level policy. That
> said, having it available from Citrix for use is a great thing for that
> company
> to donate! It's going to be difficult to balance o
> -Original Message-
> From: sebgoa [mailto:run...@gmail.com]
> Sent: Tuesday, May 20, 2014 11:30 PM
> To: dev@cloudstack.apache.org
> Subject: Re: [PROPOSAL] Using continuous integration to maintain our code
> quality...
>
>
> On May 21, 2014, at 12:40 AM,
On Wed, May 21, 2014 at 2:30 AM, sebgoa wrote:
> Why don't Citrix developers show us how they would do it in the open ? Right
> now it's all hidden.
+1 - I like some of the concepts of this proposal, but I have some
concerns as well.
I'll also state for the record, that I will -1 any decision t
>
>> -Original Message-
>> From: Trippie [mailto:trip...@gmail.com] On Behalf Of Hugo Trippaers
>> Sent: Wednesday, May 14, 2014 12:32 AM
>> To: dev@cloudstack.apache.org
>> Subject: Re: [PROPOSAL] Using continuous integration to maintain our code
>>
k.apache.org
> Subject: Re: [PROPOSAL] Using continuous integration to maintain our code
> quality...
>
> Hey Alex,
>
> Nice job on getting this all done and working on some guidelines to improve
> quality of the overal guidelines. We discussed a lot of these things at the
: Thursday, May 15, 2014 5:01 PM
To: dev@cloudstack.apache.org
Subject: RE: [PROPOSAL] Using continuous integration to maintain our code
quality...
> On Wed, May 14, 2014 at 06:21:34PM +, Alex Huang wrote:
> > I think infrastructure code should just be checked in with the source
>
On Wed, May 7, 2014 at 11:20 AM, Donal Lafferty
wrote:
> Can we introduce a penalty points system to get them to slow down?
>
> E.g. 3 pts / offence, mandatory 3rd party code reviewers after 15 over two
> releases cycles?
Penalty will only work in combination with positive incentives. If not
pe
On 14-May-2014, at 3:33 AM, Amogh Vasekar wrote:
> Hi,
>
> On 5/13/14 1:04 AM, "Daan Hoogland" wrote:
>
>> If I understood Alex' page on the wiki correctly you can run against
>> your own fork.
>
> I think Non-committers can't have a feature branch on git (at least I
> can't create one)
>
> On Wed, May 14, 2014 at 06:21:34PM +, Alex Huang wrote:
> > I think infrastructure code should just be checked in with the source
> > code. To separate it means you have to deal with version
> > match/mismatch between infrastructure and source code.
>
> Sorry - that doesn't sound right. Usu
On Thu, May 15, 2014 at 09:01:16PM +, Alex Huang wrote:
> > On Wed, May 14, 2014 at 06:21:34PM +, Alex Huang wrote:
> > > I think infrastructure code should just be checked in with the source
> > > code. To separate it means you have to deal with version
> > > match/mismatch between infras
Alex,
I applaud the effort and everybody at Citrix contributing to it.
This is not a concern with your proposed process: I hope it does not
impede the efforts to have a distributed setup where everybody can
start their tests specific to their hardware from the central jenkins
on their local jenkin
reviewer put it through CI for you.
--Alex
> -Original Message-
> From: Ritu Sabharwal [mailto:rsabh...@brocade.com]
> Sent: Wednesday, May 7, 2014 11:23 AM
> To: Alex Huang
> Cc: dev@cloudstack.apache.org
> Subject: FW: [PROPOSAL] Using continuous integration to maintain o
On Wed, May 14, 2014 at 06:21:34PM +, Alex Huang wrote:
> I think infrastructure code should just be checked in with the
> source code. To separate it means you have to deal with version
> match/mismatch between infrastructure and source code.
Sorry - that doesn't sound right. Usually infra
Hey Alex,
Nice job on getting this all done and working on some guidelines to improve
quality of the overal guidelines. We discussed a lot of these things at the
last CCC and i’m happy to see them here.
I do have some feedback on the policy though.
Specifically with the line stating “No merges
ycles?
> -Original Message-
> From: Alex Huang [mailto:alex.hu...@citrix.com]
> Sent: 07 May 2014 01:04
> To: dev@cloudstack.apache.org
> Subject: [PROPOSAL] Using continuous integration to maintain our code
> quality...
>
> Hi All,
>
> This is something I br
: Tuesday, May 06, 2014 5:04 PM
To: dev@cloudstack.apache.org
Subject: [PROPOSAL] Using continuous integration to maintain our code quality...
Hi All,
This is something I brought up a long time ago but really didn't have the
resources to get it all up and running until now. Throughout the past
Thanks Alex for the information!
-Original Message-
From: Alex Huang [mailto:alex.hu...@citrix.com]
Sent: Wednesday, May 07, 2014 2:56 PM
To: Ritu Sabharwal
Cc: dev@cloudstack.apache.org
Subject: RE: [PROPOSAL] Using continuous integration to maintain our code
quality...
Hi Ritu
> Sent: Tuesday, May 13, 2014 10:25 PM
> To: dev@cloudstack.apache.org
> Subject: RE: [PROPOSAL] Using continuous integration to maintain our code
> quality...
>
> Infrastructure code related changes done\in progress, related to this
> proposal, currently are maintained in a
uesday, May 13, 2014 3:08 PM
> To: dev@cloudstack.apache.org
> Subject: Re: [PROPOSAL] Using continuous integration to maintain our code
> quality...
>
> Sorry, I take that back. Misunderstood the "fork" to be "feature" branch on
> cloudstack git.
>
> Amogh
&g
lex.hu...@citrix.com]
> Sent: Tuesday, May 13, 2014 3:43 PM
> To: dev@cloudstack.apache.org
> Subject: RE: [PROPOSAL] Using continuous integration to maintain our code
> quality...
>
> Noji,
>
> Everything should be checked in under tools. I'll make sure
let the reviewer put it through CI for you.
"
--Alex
> -Original Message-
> From: Daan Hoogland [mailto:daan.hoogl...@gmail.com]
> Sent: Tuesday, May 13, 2014 1:04 AM
> To: dev
> Subject: Re: [PROPOSAL] Using continuous integration to maintain our code
> quality...
&
On May 6, 2014, at 8:03 PM, Alex Huang wrote:
> Hi All,
>
> This is something I brought up a long time ago but really didn't have the
> resources to get it all up and running until now. Throughout the past year,
> Edison, Prasanna, Amogh, Bharat, Koushik, Talluri, and others have been
> chi
@cloudstack.apache.org
Subject: RE: [PROPOSAL] Using continuous integration to maintain our code
quality...
Noji,
Everything should be checked in under tools. I'll make sure of that. None of
the code/configuration should be private.
--Alex
> -Original Message-
>
Hi,
On 5/13/14 1:04 AM, "Daan Hoogland" wrote:
>If I understood Alex' page on the wiki correctly you can run against
>your own fork.
I think Non-committers can't have a feature branch on git (at least I
can't create one)
Thanks,
Amogh
2014 8:20 AM
> To: dev@cloudstack.apache.org
> Subject: Re: [PROPOSAL] Using continuous integration to maintain our code
> quality...
>
> Alex,
>
> Thank you for interesting proposal. I suppose pre check-in test is long-
> awaited for everyone.
> I'm looking
Sorry, I take that back. Misunderstood the "fork" to be "feature" branch
on cloudstack git.
Amogh
On 5/13/14 3:03 PM, "Amogh Vasekar" wrote:
>Hi,
>
>On 5/13/14 1:04 AM, "Daan Hoogland" wrote:
>
>>If I understood Alex' page on the wiki correctly you can run against
>>your own fork.
>
>I think N
central repository. In that
>> case, does it mean that I install Jenkins locally on my setup.
>>
>> Please help.
>>
>> Thanks,
>> Ritu S.
>>
>> -Original Message-
>> From: Alex Huang [mailto:alex.hu...@citrix.com]
>> Sent: Tue
Alex, (see inline)
On Mon, May 12, 2014 at 6:02 PM, Alex Huang wrote:
...
> For the concern on distributed setup, there's a two part answer.
> 1. We're basically asking everyone to use a central Jenkins to run the
> automated before they merge to the asf git repository to make sure they
> did
lly on my setup.
>
> Please help.
>
> Thanks,
> Ritu S.
>
> -Original Message-
> From: Alex Huang [mailto:alex.hu...@citrix.com]
> Sent: Tuesday, May 06, 2014 5:04 PM
> To: dev@cloudstack.apache.org
> Subject: [PROPOSAL] Using continuous integration to ma
continue to update the
list.
--Alex
> -Original Message-
> From: Daan Hoogland [mailto:daan.hoogl...@gmail.com]
> Sent: Wednesday, May 7, 2014 3:34 AM
> To: dev
> Subject: Re: [PROPOSAL] Using continuous integration to maintain our code
> quality...
>
> Alex,
: [PROPOSAL] Using continuous integration to maintain our code quality...
Hi All,
This is something I brought up a long time ago but really didn't have the
resources to get it all up and running until now. Throughout the past year,
Edison, Prasanna, Amogh, Bharat, Koushik, Talluri, and others have
Hi All,
This is something I brought up a long time ago but really didn't have the
resources to get it all up and running until now. Throughout the past year,
Edison, Prasanna, Amogh, Bharat, Koushik, Talluri, and others have been
chipping away at it. At this point, we finally pull together a
64 matches
Mail list logo
