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

[Pranith Kumar Karampuri]

On 05/09/2015 12:33 AM, Jeff Darcy wrote:
>> I submit a patch for new-component/changing log-level of one of the logs
>> for which there is not a single caller after you moved it from INFO ->
>> DEBUG. So the code is not at all going to be executed. Yet the
>> regressions will fail. I am 100% sure it has nothing to do with my
>> patch. I neither have time nor expertise to debug the test that I have
>> no clue about, so the least I can do is to intimate people who may do
>> something about it i.e. owner of test or maintainer of module. You feel
>> lets ask the owner of the test about what the problem is, owner of the
>> test moves on to different component and is busy with their own work. So
>> you are left with going to the maintainer who tells you so and so is the
>> problem and so and so is the reason as soon as you show the test number,
>> so you end up feeling why didn't I ask him/her first.
> What you describe sounds more like a problem than a solution.  The
> component maintainers shouldn't be the only ones who have this
> information.
I think this is already solved by having the public pad.
> Both patch submitters and test owners should be able
> to find it on a public test-status page.
Yes, they are already refering to the pad.
> The test owner should be
> *very* well aware of the problem, because it should be at or near the
> top of their priority list.
What is so special about 'test' code? 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?
> 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.
> Assigning primary
> responsibility to maintainers has the exact opposite effects.