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

[Jeff Darcy]

----- Original Message -----
> On Fri, Jan 08, 2016 at 05:11:22AM -0500, Jeff Darcy wrote:
> > [08:45:57] ./tests/basic/afr/arbiter-statfs.t ..
> > [08:43:03] ./tests/basic/afr/arbiter-statfs.t ..
> > [08:40:06] ./tests/basic/afr/arbiter-statfs.t ..
> > [08:08:51] ./tests/basic/afr/arbiter-statfs.t ..
> > [08:06:44] ./tests/basic/afr/arbiter-statfs.t ..
> > [08:00:54] ./tests/basic/afr/self-heal.t ..
> > [07:59:56] ./tests/basic/afr/entry-self-heal.t ..
> > [18:05:23] ./tests/basic/quota-anon-fd-nfs.t ..
> > [18:06:37] ./tests/basic/quota-nfs.t ..
> > [18:49:32] ./tests/basic/quota-anon-fd-nfs.t ..
> > [18:51:46] ./tests/basic/quota-nfs.t ..
> > [14:25:37] ./tests/basic/quota-anon-fd-nfs.t ..
> > [14:26:44] ./tests/basic/quota-nfs.t ..
> > [14:45:13] ./tests/basic/tier/record-metadata-heat.t ..
> 
> That is 6 tests, they could be disabled or ignored.

And tomorrow a different six, and the day after that another, and so on
until we're not testing anything.  I ask again: how is this really any
different than doing NetBSD tests post merge, other than the fact that
it requires more resources and has the side effect of blocking unrelated
patches?

> > So some of us *have* done that work, in a repeatable way.  Note that the
> > list doesn't include tests which *hang* instead of failing cleanly,
> > which has recently been causing the entire NetBSD queue to get stuck
> > until someone manually stops those jobs.  What I find disturbing is the
> > idea that a feature with no consistently-available owner or identifiable
> > users can be allowed to slow or block every release unless every
> > developer devotes extra time to its maintenance.  Even if NetBSD itself
> > is worth it, I think that's an unhealthy precedent to set for the
> > project as a whole.
> 
> For that point, we could start the regression script by:
> ( sleep 7200 && /sbin/reboot -n ) &
> 
> And end it with:
> kill %1
> 
> Does it seems reasonable? That way nothing can hang more than 2 hours.

That addresses the technical issue of hanging tests.  It doesn't address
the process issue of the entire project and development team being held
hostage to one feature.