d51c59002367 added a Lua script to process the lists of candidate and completed MFC commits to address sorting issues in the original shell implementation. Instead of having a mix of shell and Lua, implement the entire tool in Lua.
Details
- Reviewers
imp - Group Reviewers
srcmgr - Commits
- rG48f3fcabea80: mfc-candidates: Convert to Lua
Diff Detail
- Repository
- rG FreeBSD src repository
- Lint
Lint Not Applicable - Unit
Tests Not Applicable
Event Timeline
For reference, wall time listing my outstanding main>stable/14 candidates:
x main + D47416 +------------------------------------------------------------------------------+ | + x | |+ ++ + x x x x| | |___A__| |_____M_A_______| | +------------------------------------------------------------------------------+ N Min Max Median Avg Stddev x 5 0.99 1.09 1.02 1.032 0.046043458 + 5 0.65 0.7 0.68 0.676 0.018165902 Difference at 95.0% confidence -0.356 +/- 0.0510455 -34.4961% +/- 3.51838% (Student's t, pooled s = 0.035)
tools/tools/git/mfc-candidates.lua | ||
---|---|---|
8 | Should the license comment be the first comment? |
tools/tools/git/mfc-candidates.lua | ||
---|---|---|
8 | The current style that we've been promoting is to have the license stuff first and to have it in the order copyright, SPDX identifier, though I've not published that policy. that order is the most standard order in the rest of open source, though I know when we have big boiler plate files we list SPDX above the copyright. |
This looks ready enough. I just had a quick question, one minor tweak that's optional and a general grump about command line parsing in Lua
tools/tools/git/mfc-candidates.lua | ||
---|---|---|
78 | why 40? | |
130 | maybe this should be 'os.getenv("FREEBSD_USER") or os.getenv("USER") or ""' | |
160 | Option parsing is a big reason I've done things in python :) |
tools/tools/git/mfc-candidates.lua | ||
---|---|---|
78 | a git sha-1 hash is 40 characters | |
130 | We don't have any existing use of FREEBSD_USER, right? This is to accommodate the case where someone's @freebsd.org user id does not match their local user, I presume? Yeah, I agree we should do something like that, but I'm not sure exactly what so would like to revisit this in a subsequent look. | |
160 | yeah it's a bit janky |