On Thu, Sep 23 2021, Junio C Hamano wrote: > Ævar Arnfjörð Bjarmason <avarab@xxxxxxxxx> writes: > >>> * ab/sanitize-leak-ci (2021-09-20) 2 commits >>> - tests: add a test mode for SANITIZE=leak, run it in CI >>> - Makefile: add SANITIZE=leak flag to GIT-BUILD-OPTIONS >>> >>> CI learns to run the leak sanitizer builds. >>> >>> Will merge to 'next'? >> >> Yes please, as noted in >> https://lore.kernel.org/git/87r1dh8r62.fsf@xxxxxxxxxxxxxxxxxxx/ more >> leak fixes are waiting on this. > > Isn't the direction of dependency the other way? Once fixes go in, > checks will no longer complain, but until fixes are reviewed and > applied, checking at CI will break the testing and this would need > working around by marking various tests as "not ready to be tested". The fixes are structured as fixing the code, and then for both self-documentation & testing turning on: TEST_PASSES_SANITIZE_LEAK=true In the same commit, I could fix the leaks and have a second series later for turning on the regression test, or just turning on the test and having it kick in once it's merged with ab/sanitize-leak-ci, but waiting until ab/sanitize-leak-ci hit master first seemed less confusing for everyone. But if you'd like to have 'em now with either of those caveats... >> It seems due to the size of this series we might be better off splitting >> up this already split-up series. >> >> I was trying to convince you to merge down the much more trivial changes >> up to the <mark0> above, which are purely build system prep work. Any >> chance you'd reconsider? >> >> I think a plan that might be better would be: >> >> 1. Eject both ab/config-based-hooks-base & es/config-based-hooks >> 2. I'd submit a series up to the <mark0>, hopefully that can land fairly >> soon thereafter. >> 3. Once that's in, another one for <mark0>..<mark1>, i.e. the "git hook >> run" command, but only the more basic bits, and migrating fairly >> simple hooks. >> 4. Then <mark1>..<mark2>, followed by <mark2>..ab/config-based-hooks-base >> 5. Then Emily's es/config-based-hooks. >> >> That's converting a 2-step process (ab/config-based-hooks-base + >> es/config-based-hooks) into 5 steps, but I suspect it would go faster, >> right now it seems there's no takers for a review of this rather large >> series. What do you & Emily think? [Just for anyone reading along, I've since pulled the trigger on that proposed plan at https://lore.kernel.org/git/cover-0.8-00000000000-20210923T095326Z-avarab@xxxxxxxxx/] > Today I learned a phrase "six of one and half a dozen of another" ;-) > > I have been wondering if something like a book reading club is > doable on the list. A chairperson nominates (and perhaps resends) a > series of patches that is of manageable size to be reviewed, perhaps > even prime the discussion with some comments, likeminded folks chime > in and we end up with a reviewed series? Some of your colleagues at Google have been running such a review for what I understand to have been a while, and have recently started inviting external people. I attended one & applaud the effort. I think we could run a similar thing here on-list if there's interest (I'd participate). Perhaps just: 1. Include a list of un-loved topics in What's Cooking (or someone could do it as a follow-up) 2. Pick N, and distill it down to one, either asa BDFL decision or via some easy voting mechanism, like https://doodle.com or E-Mail replies. 3. Send out a call for reviews with a re-send some time (a week?) later. If you're not up for organizing it with everything you've got on your plate I'd be up for doing it. I'd basically just: 1. Read What's Cooking, subjectively note topics that seem to need love. 2. Pick one for next week's on-list review club. Via the BFDL-decreed methof of "shuf | head -n 1" or similar. 3. Send out weekly REVIEW CLUB E-Mail with a link to the relevant series (if active), or have it be a --cover-letter with a full re-send if it's been dead on-list for long enough for nobody to be bothered by two parallel threads as a result. What do you & others think?
