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@xxxxxxxxxx> > To: "Atin Mukherjee" <amukherj@xxxxxxxxxx>, "Joseph Fernandes" <josferna@xxxxxxxxxx>, "Avra Sengupta" > <asengupt@xxxxxxxxxx> > Cc: "gluster-infra" <gluster-infra@xxxxxxxxxxx>, "Gluster Devel" <gluster-devel@xxxxxxxxxxx> > Sent: Thursday, January 7, 2016 2:50:17 PM > Subject: Re: [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@xxxxxxxxxx> > >> To: "Gluster Devel" <gluster-devel@xxxxxxxxxxx>, "gluster-infra" > >> <gluster-infra@xxxxxxxxxxx> > >> Sent: Thursday, January 7, 2016 11:51:51 AM > >> Subject: Re: [Gluster-infra] 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@xxxxxxxxxxx > >>> http://www.gluster.org/mailman/listinfo/gluster-infra > >> _______________________________________________ > >> Gluster-infra mailing list > >> Gluster-infra@xxxxxxxxxxx > >> http://www.gluster.org/mailman/listinfo/gluster-infra > >> _______________________________________________ > >> Gluster-devel mailing list > >> Gluster-devel@xxxxxxxxxxx > >> http://www.gluster.org/mailman/listinfo/gluster-devel > >> > > _______________________________________________ > > Gluster-infra mailing list > > Gluster-infra@xxxxxxxxxxx > > http://www.gluster.org/mailman/listinfo/gluster-infra > > _______________________________________________ > Gluster-devel mailing list > Gluster-devel@xxxxxxxxxxx > http://www.gluster.org/mailman/listinfo/gluster-devel > _______________________________________________ Gluster-devel mailing list Gluster-devel@xxxxxxxxxxx http://www.gluster.org/mailman/listinfo/gluster-devel
