I'm not sure the etiquette here; I'm accepting the revision since it obviously fixes a bug, but still would like the comments to be considered/responded to?
Tue, Oct 19
Mon, Oct 18
I feel like the proposal is going in the wrong direction because it make a more diverse set of version passe the version checks while I feel like we need to more toward a narrower check. Different formater version tends to produce different results and it seems saner to pin the project to specific versions (that we update from time to time).
Sun, Oct 17
Fri, Oct 15
Looks good to me aside from the nit and the pulkit's comment. Not sure on etiquette here (whether I should mark as accepted or not), defaulting to not marking as accepted until all outstanding comments are addressed.
The CI running on Heptapod is available to any developer who pushs draft to it, and it uses the "correct" black version, pinned in the docker image what we uses for the CI.
Something we have been entertaining for a while is to a manually trigger a CI "job" that would run the black formatter one current stack and push back the result to heptapod. This would give a simple option to format with the right version when the CI complains about it. It looks like it could fit the @spectral usecase here.
(The docker image can be easily updated to newer version when appropriate by anyone creating a Merge request here: https://foss.heptapod.net/octobus/ci-dockerfiles/)
While this is/would be very useful, it requires manual action, I think?
Yes, it would be an optional way for people who don't want (or can't easily) install the required tools at the required version.
My goal is to prevent that. I want/need there to be a single command I can run that ensures a commit is ready to land: correctly formatted, tests pass, etc.; there's a reason these check-format tests exist as tests. :/
I am not challenging that, but whatever we do with these tests need to be viable at the project level and it don't seems like using too many, incompatible, version of the formatter would fly well.
I think the baseline for the project should be "the CI shoul stay green" which implies "new changesets should keep the CI green". Running tests locally is a good way to quickly catch errors, but eventually, the only way to validate this is to run the CI on submitted changeset. Something that is now easy to do for a couple of years.
However this implies to make sure the version of formatter used by developers is aligned with the one used by the CI. Which should not be to complicated.
Mon, Sep 27
Sep 9 2021
Sep 7 2021
I think that the worst that can happen with this change is:
a. clang-format makes a backwards-incompatible change
This has happened (in the past, anyway) pretty regularly. When I asked djasper about it, his answer was "you should check in the clang-format binary you want to test against" which we obviously can't do. :/
Jul 30 2021
Jul 27 2021
May 17 2021
Looks like these changes were absorbed into 8fcc0a82, so this is unnecessary now.
May 6 2021
May 2 2021
May 1 2021
I'm not sure that this is an improvement. We discussed whether we want to hard-wire the version even stricter ("exactly version 11"), especially because it is hard to predict when the output is going to change again.
Apr 30 2021
This breaks the CI https://foss.heptapod.net/octobus/mercurial-devel/-/pipelines/21383.
Could you send a followup please?
Apr 29 2021
Apr 28 2021
I thought I'd run the entire test suite and it passed before sending. Sorry about that! Fixed fncache and inherit-mode by not writing out the narrowspec backup in the mkstemp call. I'm not getting any failures in test-check-code.t, can you share what ones you're seeing?
(marking comment as resolved, not sure what the exact policy is here :))
Apr 20 2021
@spectral, What is the range of code you want to ensure a race with ? and how is the synchronization happening to reach it ?
Apr 19 2021
I'm unable to reproduce. I've run the test over 10,000 times (I added a #testcases a b c d e f g h i j k l m n o p q r s t u v w x y z so it ran 26 times each run, and I've run over 300 instances of that like run-tests.py -j26 -l --chg test-racy-mutations.t, over 100 with -j108, and other combinations (with and without the added testcases, with and without --chg, etc.)
I'm apparently not going to resolve the comments, sorry for leaving this open so long.
Apr 14 2021
Fails to apply cleanly on current tip of default branch. Kindly rebase and resend.