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

Thu Jan 7 11:37:00 UTC 2016

As Avra mentioned we should trigger regressions for pathces which got +2.
That would save lot of regression cycles.

Thanks and Regards,
Kotresh H R

----- Original Message -----
> From: "Aravinda" <avishwan at redhat.com>
> To: "Atin Mukherjee" <amukherj at redhat.com>, "Joseph Fernandes" <josferna at redhat.com>, "Avra Sengupta"
> <asengupt at redhat.com>
> Cc: "gluster-infra" <gluster-infra at gluster.org>, "Gluster Devel" <gluster-devel at gluster.org>
> Sent: Thursday, January 7, 2016 2:50:17 PM
> Subject: Re: [Gluster-devel] [Gluster-infra] NetBSD tests not running to completion.
> 
> 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
> 
> _______________________________________________
> Gluster-devel mailing list
> Gluster-devel at gluster.org
> http://www.gluster.org/mailman/listinfo/gluster-devel
> 