Ludovic Courtès <[email protected]> writes:
Andreas Enge <[email protected]> skribis:
With opt-in, my fear is that we will never finish,
With opt-out, my fear is that we will never start :-) because
we’re
talking about several thousand packages that will need to be
checked
manually.
Here are some stats for substitute* calls:
- 8643 total pattern matches
- 490 matching files
- 308 files with < 10 matches
- 12 files with > 100 matches:
327 ./gnu/packages/ruby-xyz.scm
317 ./gnu/packages/bioinformatics.scm
242 ./gnu/packages/python-xyz.scm
214 ./gnu/packages/games.scm
213 ./gnu/packages/gnome.scm
198 ./gnu/packages/emacs-xyz.scm
185 ./gnu/packages/lisp-xyz.scm
182 ./gnu/packages/linux.scm
182 ./gnu/packages/java.scm
178 ./gnu/packages/maths.scm
107 ./gnu/packages/admin.scm
101 ./gnu/packages/machine-learning.scm
Based on the above, I agree that opt-out is a non-starter without
some plan for incremental migration. What do folks think about the
following?
For the sake of argument, let's say that the new, stricter version
of the helper is initially named substitute**.
1) One module at a time, rebind substitute* to substitute**,
rebuild, and fix errors. For the files with hundreds of matches,
maybe place the rebinding closer to the bottom of the file to
limit its scope, then move it toward the top over successive PRs.
2) When all modules have been migrated, change the definition of
substitute* to match substitute**
3) Remove per-module rebindings of substitute*, and finally remove
substitute** itself
By its nature, the work shards nicely across teams (or across any
set of folks that commit to it).
with a deadline to switch from opt-in to opt-out to make sure we
eventually finish!
I agree that a firm date for advancing from step #1 to #2 would
probably help.
Jason
