For reference, see the general release schedule of v25.0 here: bitcoin/bitcoin#26549
- Between Feature Freeze (2023-04-01) and RC1 tagging (2023-04-14) anyone can open a PR to the asmap-data repo in the Bitcoin Core org (needs to be recreated, demo here). The map can be created with the tool that is most ready and should have rough consensus that it is safe to be used for this purpose: asmapy, sipasmap and kartograf (TBD).
- Anyone can review the PRs and candidate files using tools, such as asmapy/sipasmap diffing, kartograf coverage report, etc. There should be some documentation at one place listing the tools that are possible to use for reviewing but the emphasis should also be on people exploring different ways and using ankles that are only available to them, i.e. check if their own node IP is mapped to the correct AS and testing the file in their own node for example.
- By the time rc1 is tagged, maintainers should decide on one candidate file to be used in the release, based on the reviews (that's probably a bit tight, especially when we do this for the first time). The candidate file can still receive review until final is tagged, of course, and it may be swapped for another one if issues are discovered with the chosen file. If the file is swapped it should be included in at least one more rc and that rc should be given at least one more week of testing.
- As part of the build process the chosen file is pulled from the asmap-data, compressed, and embedded into the binary. The hash of the file should be validated and logged so that users can compare it to the hash of the file they can download from asmap-data and audit.
- The file is embedded in the v25.0 binary. TBD if asmap should be used as default already with the first version that has an asmap embedded, it should probably be opt-in via a flag as this first step.
For completeness adding this here: In a parallel conversation in another gist about the use of diffs to increase trust the candidate file, I made the following statement that might be relevant here:
"Maybe the most likely way of making this work I can see right now is the following: When you want to open a PR as described in Step 1 here then you could tell @brunoerg privately about it and ask him to generate the file at the same time with the same process. You open the PR and then Bruno comments, saying that you both collaborated and what his differences were, and that he thinks the file is good. I personally would still give this file the same scrutiny and I would also discount Bruno's ACK a bit (if he even gives it explicitly), similar to how I would view a PR that would include individual commits from both of you. But this may give you an additional boost from other individual reviewers and maybe over time this turns into a standard as the files that were created in this way get more reviews/ACKs and tend to be used in the binary over those created by only one contributor."