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
_______________________________________________
Gluster-devel mailing list
Gluster-devel@xxxxxxxxxxx
http://www.gluster.org/mailman/listinfo/gluster-devel
