Re: What's cooking in git.git (Sep 2021, #06; Mon, 20)
From: Ævar Arnfjörð Bjarmason <hidden>
Date: 2021-09-23 17:05:31
On Thu, Sep 23 2021, Junio C Hamano wrote:
Ævar Arnfjörð Bjarmason [off-list ref] writes:quoted
quoted
* 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@evledraar.gmail.com/ (local) 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...
quoted
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@gmail.com/ (local)]
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?