sbp commented on issue #643: URL: https://github.com/apache/tooling-trusted-releases/issues/643#issuecomment-3908893523
Here's a very quick survey of parameters: | Count | Parameter | |-------|-----------| | **55** | `project_name` | | **48** | `version_name` | | **19** | `project` | | **19** | `version` | | **9** | `name` | | **9** | `revision` | | **7** | `file_path` | | **3** | `revision_number` | | **3** | `fingerprint` | | **3** | `committee_name` | The `name` parameter is ambiguous, so we should fix that. Sometimes we use it for projects and sometimes committees. All instances of `file_path` use the `path:` converter. The `project` and `version` parameters are the API style for doing it, which I started doing experimentally because I didn't like the verbosity of `project_name` and `version_name`. (The problem is that these tend to clash with object variables for the same, so I'm still not really sure which style I prefer. Probably `version_name` is better than `version`, but the `_name` suffix is clunky and weird for a version. Everybody calls them _version numbers_ usually, but they're not always numbers! Naming is hard.) Anyway, the reason for this survey is because @dave2wave suggested that we do automatic validation of some parameters in our decorators. The results show that we should focus on project and version parameters first. More interestingly and unexpectedly, they also show that we actually have a very limited range of parameters, which makes it more feasible that we could automatically validate them all. -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: [email protected] For queries about this service, please contact Infrastructure at: [email protected] --------------------------------------------------------------------- To unsubscribe, e-mail: [email protected] For additional commands, e-mail: [email protected]
