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

[Aravinda]

I think not having NetBSD runs for every patch will introduce new set of 
problems, like
     - who will debug the nightly failures?
     - If NetBSD failures queued up everyday, then how to address those 
issues
     - Additional overhead to identify which patch caused nightly build 
failure

regards
Aravinda

On 01/07/2016 01:53 PM, Atin Mukherjee wrote:
> 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
>>
> _______________________________________________
> Gluster-infra mailing list
> Gluster-infra at gluster.org
> http://www.gluster.org/mailman/listinfo/gluster-infra