[Gluster-devel] good job on fixing heavy hitters in spurious regressions

[Pranith Kumar Karampuri]

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.