Justin Clift wrote:
> > What about ading another nb7build user in gerrit? That way results will
> > not conflict.
>
> I'm not sure.
What makes you doubt? When multiple user cast votes, they do not overide
each others?
--
Emmanuel Dreyfus
http://hcpnet.free.fr/pubz
m...@netbsd.org
__
On 1 Apr 2015, at 17:38, Emmanuel Dreyfus wrote:
> Justin Clift wrote:
>
>> We need some kind of solution.
>
> What about ading another nb7build user in gerrit? That way results will
> not conflict.
I'm not sure. However, Vijay's now added me as an admin in our
production Gerrit instalce, and
believe that this problem may be with the version of the old Gerrit,
because I Gerrit in 2.10.2 version and Jenkins in 1.596.1 and squeegee
build tests that take up to 96 hours in codesonar and return the voting
Gerrit verified +1 or -1.
firemanxbr
On Wed, Apr 1, 2015 at 1:38 PM, Emmanuel Dreyfu
Justin Clift wrote:
> We need some kind of solution.
What about ading another nb7build user in gerrit? That way results will
not conflict.
--
Emmanuel Dreyfus
http://hcpnet.free.fr/pubz
m...@netbsd.org
___
Gluster-devel mailing list
Gluster-devel@glu
yep, using on Jenkins the plugin Gerrit Trigger, this plugin trigger all
requests for all repositories and all branches, this function running with
Auto QA tests and vote with ACL "verified", for example:
https://gerrit.ovirt.org/#/c/37886/
my intention is make one deploy with one complete exa
On 1 Apr 2015, at 17:20, Marcelo Barbosa wrote:
> yep, using on Jenkins the plugin Gerrit Trigger, this plugin trigger all
> requests for all repositories and all branches, this function running with
> Auto QA tests and vote with ACL "verified", for example:
>
>https://gerrit.ovirt.org/#/c/
On Wed, Apr 01, 2015 at 12:50:30PM +0530, Vijay Bellur wrote:
> I think all we need is to create another gerrit user like "NetBSD
> Regression" or so and have verified votes routed through this user. Just as
> multiple users can provide distinct CR votes, we can have multiple build
> systems provid
On 04/01/2015 09:42 AM, Justin Clift wrote:
On 1 Apr 2015, at 05:04, Emmanuel Dreyfus wrote:
Justin Clift wrote:
That, or perhaps we could have two verified fields?
Sure. Whichever works. :)
Personally, I'm not sure how to do either yet.
In http://build.gluster.org/gerrit-trigger/ you
Openstack uses Zuul [1], which manages this kinds of issues. Maybe we
can explore it.
This was brought up sometime before by Prashant Pai (I don't remember
if it was on IRC or here).
~kaushal
[1] http://ci.openstack.org/zuul/
___
Gluster-devel mailing
On 1 Apr 2015, at 05:04, Emmanuel Dreyfus wrote:
> Justin Clift wrote:
>
>>> That, or perhaps we could have two verified fields?
>>
>> Sure. Whichever works. :)
>>
>> Personally, I'm not sure how to do either yet.
>
> In http://build.gluster.org/gerrit-trigger/ you have "Verdict
> categories
Justin Clift wrote:
> > That, or perhaps we could have two verified fields?
>
> Sure. Whichever works. :)
>
> Personally, I'm not sure how to do either yet.
In http://build.gluster.org/gerrit-trigger/ you have "Verdict
categories" with CRVW (code review) and VRIF (verified), and there is a
"a
On 1 Apr 2015, at 04:07, Emmanuel Dreyfus wrote:
> Justin Clift wrote:
>
>> It sounds like we need a solution to have both the NetBSD and CentOS
>> regressions run, and only give the +1 when both of them have successfully
>> finished. If either of them fail, then it gets a -1.
>
> That, or per
Justin Clift wrote:
> It sounds like we need a solution to have both the NetBSD and CentOS
> regressions run, and only give the +1 when both of them have successfully
> finished. If either of them fail, then it gets a -1.
That, or perhaps we could have two verified fields?
--
Emmanuel Dreyfus
On 1 Apr 2015, at 03:03, Emmanuel Dreyfus wrote:
> Jeff Darcy wrote:
>
>> That's fine. I left a note for you in the script, regarding what I
>> think it needs to do at that point.
>
> Here is the comment:
>
>> # We shouldn't be touching CR at all. For V, we should set V+1 iff this
>> # test
Jeff Darcy wrote:
> That's fine. I left a note for you in the script, regarding what I
> think it needs to do at that point.
Here is the comment:
> # We shouldn't be touching CR at all. For V, we should set V+1 iff this
> # test succeeded *and* the value was already 0 or 1, V-1 otherwise. I
>
> > > http://review.gluster.org/#/c/9970/ (Kotresh HR)
> > > extras: Fix stop-all-gluster-processes.sh script
>
> Theses are the NetBSD regression failures for which we got fixes merged
> recently. Doesn't it just need to be rebased?
Quite possibly. I wasn't looking at patch contents all
Jeff Darcy wrote:
> > http://review.gluster.org/#/c/9970/ (Kotresh HR)
> > extras: Fix stop-all-gluster-processes.sh script
Theses are the NetBSD regression failures for which we got fixes merged
recently. Doesn't it just need to be rebased?
I re-enabled NetBSD regression, with voting d
> I've done the first one. I'll leave the others for you, so you
> embed the skill :)
Done. Thanks! I also canceled the now-superfluous jobs. Maybe
in my Copious Spare Time(tm) I'll write a script to do this more
easily for other obviously-spurious regression results.
_
On 1 Apr 2015, at 00:48, Jeff Darcy wrote:
>> The following Gerrit patchsets were affected:
>>
>>http://review.gluster.org/#/c/9557/ (Nandaja Varma)
>>changelog: Fixing buffer overrun coverity issues
>>
>>http://review.gluster.org/#/c/9981/ (Pranith Kumar Karampuri)
>>cluster/ec:
> The following Gerrit patchsets were affected:
>
> http://review.gluster.org/#/c/9557/ (Nandaja Varma)
> changelog: Fixing buffer overrun coverity issues
>
> http://review.gluster.org/#/c/9981/ (Pranith Kumar Karampuri)
> cluster/ec: Refactor inode-writev
>
> http://review.g
The following Gerrit patchsets were affected:
http://review.gluster.org/#/c/9557/ (Nandaja Varma)
changelog: Fixing buffer overrun coverity issues
http://review.gluster.org/#/c/9981/ (Pranith Kumar Karampuri)
cluster/ec: Refactor inode-writev
http://review.gluster.org/#/c/997
It was improperly clearing previously-set V+1 flags, even on success. That is
counterproductive in the most literal sense of the word.
___
Gluster-devel mailing list
Gluster-devel@gluster.org
http://www.gluster.org/mailman/listinfo/gluster-devel
22 matches
Mail list logo
