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.
_______________________________________________
Gluster-devel mailing list
Gluster-devel@gluster.org
http://www.gluster.org/mailman/listinfo/gluster-devel
