On 05/08/2015 08:16 AM, Jeff Darcy wrote:
Here are some of the things that I can think of: 0) Maintainers
should also maintain tests that are in their component.
It is not possible for me as glusterd co-maintainer to 'maintain'
tests that are added under tests/bugs/glusterd. Most of them don't
test core glusterd functionality. They are almost always tied to a
particular feature whose implementation had bugs in its glusterd code.
I would expect the test authors (esp. the more recent ones) to chip
in.
Good point. Nobody should be penalized for having code that everyone
else touches (or rewarded for having code that nobody dares to).
First responsibility for debugging a regression-test failure lies
with the owner of the patch that failed. If they determine that the
failure is spurious - which is easy if it's already on a list - then
responsibility falls to the owner of the test. Either should be able
to draw on the expertise of others in the group, but that doesn't
shift *responsibility*. Only when a problem has been tracked down to
a particular piece of production code should responsibility move
again - either to the person whose earlier patch caused the breakage,
or to the subsystem maintainer.
+1, could not have said it better, but chipping in my vote for the
order, owner of patch first -> owner of test -> maintainer of module,
with the said responsibility in place.
Mostly this is just common sense. Perhaps the change that's needed
is to make the fixing of likely-spurious test failures a higher
priority than adding new features. That has to be reflected not
only in Bugzilla, but also in how we schedule individual developers'
time and evaluate their progress toward goals.
_______________________________________________
Gluster-devel mailing list
Gluster-devel@xxxxxxxxxxx
http://www.gluster.org/mailman/listinfo/gluster-devel
_______________________________________________
Gluster-devel mailing list
Gluster-devel@xxxxxxxxxxx
http://www.gluster.org/mailman/listinfo/gluster-devel
