Kris,
Looking at the history of the PR, there appears to be one LGTM for testing the
PR scope. Given the size of the change, it seems appropriate to run a
regression test. However, there are no results indicating a regression test
has been run.
I also reviewed the code and left comments to m
Thanks Rajani
https://github.com/apache/cloudstack/pull/1578 has votes and tests pass.
What would be the next step ?
Best,
Kris
On 30 August 2016 at 07:24, Rajani Karuturi wrote:
> If you could get 2 LGTMs(any one from your team can also review
> and give LGTM) and if you can run BVT suite
If you could get 2 LGTMs(any one from your team can also review
and give LGTM) and if you can run BVT suite on
PR(https://github.com/apache/cloudstack/tree/master/test/integration/smoke),
they can be immediately merged.
~ Rajani
http://cloudplatform.accelerite.com/
On August 30, 2016 at 3:47 AM,
Hi All,
The Nuage Networks team is investing in ACS 4.10.0 and has several feature
PR's outstanding for review :
- https://github.com/apache/cloudstack/pull/1578
- https://github.com/apache/cloudstack/pull/1580
- https://github.com/apache/cloudstack/pull/1579
- https://github.com/a
Hi Guys,
Gave this thread a read - sorry i'm a bit late on this topic.
I agree with what Will, John and Rohit proposed. I also understand
Rajani's hesitancy - we dont want master to become a zoo.
In summary, i think the proposed workflow should avoid the zoo case and
give us structure that will
; >>> auditability
> >>>> and comparing what exists in one branch vs another.
> >>>>
> >>>> [1] https://github.com/apache/cloudstack/blob/master/tools/git/git-pr
> >>>> [2] https://github.com/apache/cloudstack/blob/master/tools/
> &
//github.com/apache/cloudstack/blob/master/tools/
> >>> git/git-fwd-merge
> >>>>
> >>>> This is my two cents anyway...
> >>>>
> >>>> *Will STEVENS*
> >>>> Lead Developer
> >>>>
> >>>> *Clo
t; On Thu, Aug 4, 2016 at 3:43 AM, Rohit Yadav >>
>>>> wrote:
>>>>
>>>>> I disagree with having only RMs to merge PRs when we're not in freeze.
>>> In
>>>>> general we've implicitly honoured this behaviour but it was
gt; > practice
> > >> and further it's understandable that they may not be able to volunteer
> > >> enough time and effort to get the PRs sorted.
> > >>
> > >>
> > >> Over past months this and similar practices have killed our commit and
>
ur commit and
> >> development momentum, and I think it's not a healthy practice for our
> >> community to engage in further. Instead, we can have committers (and in
> >> future maybe bots) to merge a PR if they have 2 LGTMs, no objections and
> >> test results from both Travis (s
Yes, I agree with this.
CVEs need to be handled in security@ and will be added to the branches
manually once they have been agreed upon there, so no PRs are needed for
them.
I also agree that exceptions can be made for version changes in POMs and
such because those are scripted changes which are
Will,
My understanding of the release principles is that all changes must have a PR
with the exception of CVE fixes. Since we must accept CVE fixes in private,
the 2 LGTM rule is applied on the security@ mailing list and on private JIRA
security ticket. I would also say that the release commi
dops.com *|* tw @CloudOps_
> >>>
> >>> On Thu, Aug 4, 2016 at 3:43 AM, Rohit Yadav >
> >>> wrote:
> >>>
> >>>> I disagree with having only RMs to merge PRs when we're not in freeze.
> >> In
> >>>> general we've impli
rstandable that they may not be able to volunteer
>>>> enough time and effort to get the PRs sorted.
>>>>
>>>>
>>>> Over past months this and similar practices have killed our commit and
>>>> development momentum, and I think it's not a healthy
> >> community to engage in further. Instead, we can have committers (and in
> >> future maybe bots) to merge a PR if they have 2 LGTMs, no objections and
> >> test results from both Travis (simulator) and Bubble/BVT/Trillian (tests
> >> against at least one and
simulator) and Bubble/BVT/Trillian (tests
>> against at least one and ideally all three hypervisors - KVM, Xen and
>> VMware).
>>
>>
>> Regards.
>>
>>
>> From: Rajani Karuturi
>> Sent: 03 August 2016 13:43:54
>&g
bjections and
> test results from both Travis (simulator) and Bubble/BVT/Trillian (tests
> against at least one and ideally all three hypervisors - KVM, Xen and
> VMware).
>
>
> Regards.
>
>
> From: Rajani Karuturi
> Sent: 03 August 2
en and VMware).
Regards.
From: Rajani Karuturi
Sent: 03 August 2016 13:43:54
To: dev@cloudstack.apache.org
Subject: Re: 4.10.0 release
ouch.. looks like my email client stripped all the new lines.
Re-sending from webmail
Hi All,
These are the proposed dates for 4.10 release (copied from anoth
ouch.. looks like my email client stripped all the new lines.
Re-sending from webmail
Hi All,
These are the proposed dates for 4.10 release (copied from another thread
by John Burwell)
* Development (master open to features and defect fixes): 1 August 2016 -
11 September 2016
* Testing: 12 - 18 Se
A newline or two wouldn't hurt, this is pretty hard to read tbh.
--
Erik
On Wed, Aug 3, 2016 at 9:27 AM, Rajani Karuturi wrote:
> Hi All,These are the proposed dates for 4.10 release (copied from
> another thread by John Burwell)* Development (master open to
> features and defect fixes): 1 Aug
Hi All,These are the proposed dates for 4.10 release (copied from
another thread by John Burwell)* Development (master open to
features and defect fixes): 1 August 2016 - 11 September 2016*
Testing: 12 - 18 September 2016* RC Voting: 19 - 25 September
2016* Release: 26 September 2016
master is open
21 matches
Mail list logo
