You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Our contributing document requires a subsystem: prefix in the git commit subjects for proposed PRs, but doesn't explain what that means. Furthermore, we've adhered very well to including these prefixes in our work to date, but as @chu11 noted in flux-framework/flux-core#2790, we've not been consistent in the naming used in these prefixes.
If we're going to be rigorous about requiring subsystem prefixes, we should probably document why we want them, as well as what an acceptable subsystem prefix is.
Here's my take, 100% good old fashioned opinion:
Since we're not using the commit subject prefix in any kind of automated way, I think of it as a hint at what parts of the code the commit touches, so that relevant developers can quickly determine if they will have expertise for a code review and/or approval. In that case something like job-info: or python: seems fine, while modules/job-info: or bindings/python: are also ok, as long as those 8-9 characters are not needed to create a terse commit description.
Since concise commit subjects are highly valued, I try to pick the shortest name that fully qualifies the code being modified, unless with the longer prefix the commit message fits within 50 characters. Therefore, instead of cmd/flux-jobs:, the subject could be just flux-jobs: since there is no other 'modules/flux-jobs or libutil/flux-jobs, etc -- it is obvious what "subsystem" I am referencing.
Of course, I may be missing some other purpose for the subsystem prefix. In which case we can discuss that here and come up with some rules to place in our contributing doc to assist future contributors.
The text was updated successfully, but these errors were encountered:
Our contributing document requires a
subsystem:
prefix in the git commit subjects for proposed PRs, but doesn't explain what that means. Furthermore, we've adhered very well to including these prefixes in our work to date, but as @chu11 noted in flux-framework/flux-core#2790, we've not been consistent in the naming used in these prefixes.If we're going to be rigorous about requiring subsystem prefixes, we should probably document why we want them, as well as what an acceptable subsystem prefix is.
Here's my take, 100% good old fashioned opinion:
Since we're not using the commit subject prefix in any kind of automated way, I think of it as a hint at what parts of the code the commit touches, so that relevant developers can quickly determine if they will have expertise for a code review and/or approval. In that case something like
job-info:
orpython:
seems fine, whilemodules/job-info:
orbindings/python:
are also ok, as long as those 8-9 characters are not needed to create a terse commit description.Since concise commit subjects are highly valued, I try to pick the shortest name that fully qualifies the code being modified, unless with the longer prefix the commit message fits within 50 characters. Therefore, instead of
cmd/flux-jobs:
, the subject could be justflux-jobs:
since there is no other'modules/flux-jobs
orlibutil/flux-jobs
, etc -- it is obvious what "subsystem" I am referencing.Of course, I may be missing some other purpose for the subsystem prefix. In which case we can discuss that here and come up with some rules to place in our contributing doc to assist future contributors.
The text was updated successfully, but these errors were encountered: