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

[Atin Mukherjee]

I have been always with this approach right from the beginning. We can
definitely have nightly if not weekly NetBSD regressions to sanitize the
changes, with that model we wouldn't need to eliminate BSD support but
we can avoid this hard dependency in patch acceptance which has haunted
us *multiple* times now.

Thanks,
Atin

On 01/07/2016 12:38 PM, Joseph Fernandes wrote:
> +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
> _______________________________________________
> Gluster-devel mailing list
> Gluster-devel at gluster.org
> http://www.gluster.org/mailman/listinfo/gluster-devel
>