]> git.madduck.net Git - etc/vim.git/blobdiff - docs/contributing/gauging_changes.md

madduck's git repository

Every one of the projects in this repository is available at the canonical URL git://git.madduck.net/madduck/pub/<projectpath> — see each project's metadata for the exact URL.

All patches and comments are welcome. Please squash your changes to logical commits before using git-format-patch and git-send-email to patches@git.madduck.net. If you'd read over the Git project's submission guidelines and adhered to them, I'd be especially grateful.

SSH access, as well as push access can be individually arranged.

If you use my repositories frequently, consider adding the following snippet to ~/.gitconfig and using the third clone URL listed for each project:

[url "git://git.madduck.net/madduck/"]
  insteadOf = madduck:

projects / etc / vim.git / blobdiff
? search:
summary | shortlog | log | commit | commitdiff | tree
raw | inline | side by side
Remove test suite from setup.py (#2824)
[etc/vim.git] / docs / contributing / gauging_changes.md
diff --git a/docs/contributing/gauging_changes.md b/docs/contributing/gauging_changes.md
index 3cfa98b3df8678312c33a723eaa8f10dccb5edda..59c40eb390902abc71c6cbd8774451b1158e05c9 100644 (file)
--- a/docs/contributing/gauging_changes.md
+++ b/docs/contributing/gauging_changes.md
@@ -9,51 +9,16 @@ enough to cause frustration to projects that are already "black formatted".
 
 ## black-primer
 
 
 ## black-primer
 
-`black-primer` is a tool built for CI (and humans) to have _Black_ `--check` a number of
-Git accessible projects in parallel. (configured in `primer.json`) _(A PR will be
-accepted to add Mercurial support.)_
-
-### Run flow
-
-- Ensure we have a `black` + `git` in PATH
-- Load projects from `primer.json`
-- Run projects in parallel with `--worker` workers (defaults to CPU count / 2)
-  - Checkout projects
-  - Run black and record result
-  - Clean up repository checkout _(can optionally be disabled via `--keep`)_
-- Display results summary to screen
-- Default to cleaning up `--work-dir` (which defaults to tempfile schemantics)
-- Return
-  - 0 for successful run
-  - \< 0 for environment / internal error
-  - \> 0 for each project with an error
-
-### Speed up runs 🏎
-
-If you're running locally yourself to test black on lots of code try:
-
-- Using `-k` / `--keep` + `-w` / `--work-dir` so you don't have to re-checkout the repo
-  each run
-
-### CLI arguments
-
-```{program-output} black-primer --help
-
-```
+`black-primer` is an obsolete tool (now replaced with `diff-shades`) that was used to
+gauge the impact of changes in _Black_ on open-source code. It is no longer used
+internally and will be removed from the _Black_ repository in the future.
 
 ## diff-shades
 
 
 ## diff-shades
 
-diff-shades is a tool similar to black-primer, it also runs _Black_ across a list of Git
-cloneable OSS projects recording the results. The intention is to eventually fully
-replace black-primer with diff-shades as it's much more feature complete and supports
-our needs better.
-
-The main highlight feature of diff-shades is being able to compare two revisions of
-_Black_. This is incredibly useful as it allows us to see what exact changes will occur,
-say merging a certain PR. Black-primer's results would usually be filled with changes
-caused by pre-existing code in Black drowning out the (new) changes we want to see. It
-operates similarly to black-primer but crucially it saves the results as a JSON file
-which allows for the rich comparison features alluded to above.
+diff-shades is a tool that runs _Black_ across a list of Git cloneable OSS projects
+recording the results. The main highlight feature of diff-shades is being able to
+compare two revisions of _Black_. This is incredibly useful as it allows us to see what
+exact changes will occur, say merging a certain PR.
 
 For more information, please see the [diff-shades documentation][diff-shades].
 
 
 For more information, please see the [diff-shades documentation][diff-shades].
 
@@ -74,7 +39,7 @@ to further information. If there's a pre-existing diff-shades comment, it'll be
 instead the next time the workflow is triggered on the same PR.
 
 The workflow uploads 3-4 artifacts upon completion: the two generated analyses (they
 instead the next time the workflow is triggered on the same PR.
 
 The workflow uploads 3-4 artifacts upon completion: the two generated analyses (they
-have the .json file extension), `diff.html`, and `.pr-comment-body.md` if triggered by a
+have the .json file extension), `diff.html`, and `.pr-comment.json` if triggered by a
 PR. The last one is downloaded by the `diff-shades-comment` workflow and shouldn't be
 downloaded locally. `diff.html` comes in handy for push-based or manually triggered
 runs. And the analyses exist just in case you want to do further analysis using the
 PR. The last one is downloaded by the `diff-shades-comment` workflow and shouldn't be
 downloaded locally. `diff.html` comes in handy for push-based or manually triggered
 runs. And the analyses exist just in case you want to do further analysis using the
vim configuration

Legalese

All content available in this repository is copyright © martin f. krafft, unless otherwise noted.

All files and their content are released under the terms of the Artistic Licence 2.0, unless otherwise noted.

The operator of this repository shall not be held liable for offending content in pages linking to or linked from these page, nor does he endorse their content unless stated otherwise.