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

[Avra Sengupta]

On 01/07/2016 03:15 PM, Jeff Darcy wrote:
>> If you do not
>> prevent integration of patches that break NetBSD regression, that will get
>> in, and tests will break one by one over time.
> On the other hand, if patch A starts blocking all merges because of
> NetBSD failures, then all platforms - including NetBSD - are denied the
> benefit of fixes in patches B through Z.  The real problem is that our
> tests are so non-deterministic, so that they pass once and a patch gets
> merged, but then fail every time after that.  The signal-to-noise ratio
> is really low, and for some reason this problem seems even worse on
> NetBSD than on Linux.  The cost of mandatory NetBSD tests is unbounded,
> sometimes small enough to be a good investment (of our time) but
> sometimes totally out of proportion to that benefit.  That's not just
> frustrating for developers; it's also a disservice to the vast majority
> of our users who might be waiting on fixes.  I'd prefer a "defined level
> of effort" approach which *might* reduce the benefit we derive from
> NetBSD testing but *definitely* keeps the cost under control.
Can we have closure on it, this time around. We all seem to be open to 
discussing these approaches, which clearly shows that this problem is 
faced by almost everyone who is sending patches. So can we have a 
decision taken this time around, and have it implemented. On the top of 
my head, we can use any of the following to take a call on this.
1. Have the component maintainers vote on one of the approaches and then 
decide.
2. Have the architects take a call based on the pros and cons of an 
approach and then decide.

Either way let's address this, once and for all in a way that it 
addresses the pain-points, instead of coming back to it every other month.
> _______________________________________________
> Gluster-devel mailing list
> Gluster-devel at gluster.org
> http://www.gluster.org/mailman/listinfo/gluster-devel