Re: [HACKERS] Re: [COMMITTERS] pgsql: Improve pg_dump regressiontests and code coverage
От | Stephen Frost |
---|---|
Тема | Re: [HACKERS] Re: [COMMITTERS] pgsql: Improve pg_dump regressiontests and code coverage |
Дата | |
Msg-id | 20170320150609.GP9812@tamriel.snowman.net обсуждение исходный текст |
Ответ на | Re: [HACKERS] Re: [COMMITTERS] pgsql: Improve pg_dump regression tests and code coverage (Tom Lane <tgl@sss.pgh.pa.us>) |
Список | pgsql-hackers |
Tom, * Tom Lane (tgl@sss.pgh.pa.us) wrote: > New tests are not zero-cost; they create a distributed burden on the > buildfarm and, by increasing the buildfarm cycle time, slow down feedback > to authors of subsequent patches. So I'm very much not on board with > any argument that "more tests are always better and don't even require > discussion". I agree with that and certainly considered it while working on these added tests. > I'd have liked to see this patch posted with some commentary along the > lines of "this improves LOC coverage in pg_dump by X%, and for me it > increases the time taken for 'make installcheck' in bin/pg_dump by Y%". > Assuming Y isn't totally out of line with X, I doubt anyone would have > objected or even bothered to review the patch in detail ... but it would > have been polite to proceed that way. About 8% increased LOC coverage for pg_dump.c (which isn't small when you consider how large that file is). The additional time seemed to be on the 5-6s range, moving the test from 35s to 40s or so. > In short, I agree with Stephen's position that test additions can get > away with less review than other sorts of changes, but I also agree with > Robert's position that that doesn't mean there's no process to follow > at all. Fair enough. Thanks! Stephen
В списке pgsql-hackers по дате отправления: