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