[Gluster-devel] [Gluster-infra] NetBSD tests not running to completion.

Joseph Fernandes josferna at redhat.com
Thu Jan 7 07:08:02 UTC 2016


+2 Avra

----- Original Message -----
From: "Avra Sengupta" <asengupt at redhat.com>
To: "Gluster Devel" <gluster-devel at gluster.org>, "gluster-infra" <gluster-infra at gluster.org>
Sent: Thursday, January 7, 2016 11:51:51 AM
Subject: Re: [Gluster-infra] [Gluster-devel] NetBSD tests not running to	completion.

The same issue keeps coming up every few months, where all patch 
acceptances comes to a grinding halt with a dependency on NetBSD 
regressions. I have been re-trigerring my patches too, and they are not 
completing. Not to mention the long wait queue for them to run in the 
first place and then having them not complete.

I know this issue has been discussed many times before and every time we 
have arrived at the conclusion that we need to have more stable tests, 
or a more robust infrastructure, but there's more to it than that. 
Here's listing down a few of the things I have observed:
1. Not many people are well versed with debugging the issues, that 
result in failure in NetBSD regression suites, simply because not many 
of us are familiar with the nuances of the platform.
2. If I am a developer interested in being a part of the gluster 
community and contributing code to it, the patches I send will have 
dependency on NetBSD regressions. When people who have been contributing 
for years now are finding it cumbersome to have the NetBSD regressions 
pass for their patches, imagine the impression and the impact on 
motivation it will have on a new developer. We need to ask ourselves how 
is this impacting a patch acceptance process.

We can atleast try a different approaches to tackle this problem instead 
of just waiting for the test suite to stabilize or the infrastructure to 
get better.
1. We can have NetBSD as a separate port, and not have patches sent to 
the master branch be dependent on it's regression.
2. We can also have a nightly NetBSD regression run, instead of running 
it per patch. If a particular regression test fails, the owner of the 
test looks into it, and we debug the issue. One might say it's just 
delaying the problem, but atleast we will not have all patches 
acceptances blocked.
3. We really need to trigger regressions only on the patches that have 
been reviewed and have gotten a +2. This will substantially bring down 
the wait time. I remember Atin bringing this up a few months back, but 
it still hasn't been implemented. Can we please have this ASAP.

Regards,
Avra

On 01/06/2016 05:49 PM, Ravishankar N wrote:
> I re triggered NetBSD regressions for 
> http://review.gluster.org/#/c/13041/3 but they are being run in silent 
> mode and are not completing. Can some one from the infra-team take a 
> look? The last 22 tests in 
> https://build.gluster.org/job/rackspace-netbsd7-regression-triggered/ 
> have failed. Highly unlikely that something is wrong with all those 
> patches.
>
> Thanks,
> Ravi
> _______________________________________________
> Gluster-infra mailing list
> Gluster-infra at gluster.org
> http://www.gluster.org/mailman/listinfo/gluster-infra

_______________________________________________
Gluster-infra mailing list
Gluster-infra at gluster.org
http://www.gluster.org/mailman/listinfo/gluster-infra


More information about the Gluster-devel mailing list