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

[Jeff Darcy]

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

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