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
