I agree. Regards, Nithya ----- Original Message ----- > From: "Atin Mukherjee" <amukherj@xxxxxxxxxx> > To: "Joseph Fernandes" <josferna@xxxxxxxxxx>, "Avra Sengupta" <asengupt@xxxxxxxxxx> > Cc: "Gluster Devel" <gluster-devel@xxxxxxxxxxx>, "gluster-infra" <gluster-infra@xxxxxxxxxxx> > Sent: Thursday, January 7, 2016 1:53:47 PM > Subject: Re: [Gluster-infra] NetBSD tests not running to completion. > > 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-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
