On 05/09/2015 02:31 AM, Jeff Darcy wrote:
What is so special about 'test' code?
A broken test blocks everybody's progress in a way that an incomplete
feature does not.

It is still code, if maintainers
are maintaining feature code and held responsible, why not test code? It
is not that maintainer is the only one who fixes all the problems in the
code they maintain, but they are still responsible for maintaining
quality of code. Why shouldn't they do the same for quality of tests
that test the component they maintain?
You said it yourself: the maintainer isn't the only one who fixes all of
the problems.  I would certainly hope that people working on a component
would keep that component's maintainer informed about what they're doing,
but that's not the same as making the component maintainer *directly*
responsible for every fix.  That especially doesn't work for "core" which
is a huge grab-bag full of different things best understood by different
people.  To turn your own question around, what's so special about test
code that we should "short-circuit" bugs to the maintainer right away?
Ah! now I understood the confusion. I never said maintainer should fix all the bugs in tests. I am only saying that they maintain tests, just like we maintain code. Whether you personally work on it or not, you at least have an idea of what is the problem and what is the solution so someone can come and ask you and you know the status of it. Expectation is not to fix every test failure that comes maintainer's way by maintainer alone. But he/she would know about problem/solution because he/she at least reviews it and merges it. We want to make sure that the tests are in good quality as well just like we make sure code is of good quality. Core is a special case. We will handle it separately.

Pranith

By putting the onus on the test owner,
we achieve two positive things: we lessen the burden on component
(or release) maintainers, and we give other people a strong incentive
to fix problems in their own (test) code.
This has been successful only when people who wrote the tests are still
working on same component.
"Owner" and "original author" are not necessarily the same thing.  If
someone is unavailable (e.g. new job), or has forgotten too much to be
effective, then ownership should already have been reassigned.  Then
"owner first" or "maintainer first" doesn't matter, because they're
the same person.  The only really tricky case is when the original
author and person most qualified to work on a test is still around but
unable/unwilling to work on fixing a test, e.g. because their employer
insists they work on something else.  Perhaps those issues are best
addressed on a different mailing list.  ;)  As far as the project is
concerned, what can we do?  Our only practical option might be to
have someone else fix the test.  If that's the case then so be it, but
that should be a case-by-case decision and not a default.  In the more
common cases, responsibility for fixing tests should rest with the
same person who's responsible for the associated production code.

_______________________________________________
Gluster-devel mailing list
Gluster-devel@gluster.org
http://www.gluster.org/mailman/listinfo/gluster-devel

Reply via email to