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

Pranith Kumar Karampuri pkarampu at redhat.com
Fri Jan 8 12:37:17 UTC 2016


>> 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.

Guys,
         I think we just need to come up with rules for considering a 
platform to have voting ability before merging the patch. Which is not 
too hard to come up with if we all put our minds to it and come up with 
something that is agreeable for everyone. Just like glusterfs goes 
through ups and downs in stability in development, the platform may also 
go thorough the same, I do agree that the platform stability shouldn't 
hinder patch acceptance be it Linux/NetBSD (I hope FreeBSD can also 
become a voting member) so the platform may come and go in the list of 
platforms that can vote based on the platform stability. We need both 
entry and exit criteria for the platform to be considered to have a vote.

Of course if we agree to the things above, when some .t fails when the 
platform is considered stable, we need to fix it. But if it is something 
that happens only on the platform (May be the loopback failure happening 
on NetBSD which emmanuel is looking at now falls into that category) 
then until these kinds of issues are fixed we shouldn't let the project 
be slowed down. Setting clear expectations as to why some platform can 
vote for patch merging will go a long way in preventing these kind of 
discussions further, may be it can even be automated and the port 
maintainer will be notified when the platform health degrades to a point 
where it has to exit the list of platforms which have vote. Even when 
the platform doesn't vote, it still runs the tests. Once the port 
maintainers solve the problems and the health for that port is better, 
it can be automatically added to the list of platforms which can vote.

For all this to happen we need data in place. Jeff's patch to find 
failures is a great addition in gathering such data. We need more such 
data points. All of us need to agree on the data points.

These are my thoughts on the matter. Comments welcome!

Pranith


More information about the Gluster-devel mailing list