Ævar Arnfjörð Bjarmason [off-list ref] writes:
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/ 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".
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?
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?
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/ 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/]
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?
On Thu, Sep 23, 2021 at 06:51:12PM +0200, Ævar Arnfjörð Bjarmason wrote:
quoted
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...
Yeah, I think it's much easier to demonstrate the leak and that it is
fixed when we have the infrastructure from that series. So the leaks
themselves can obviously be fixed without depending on that series, but
it's much easier to review the patches when we have that extra tooling.
-Peff