Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

contributing.rst: explain "subsystem" prefix requirement in git commit subject #28

Open
grondo opened this issue Mar 2, 2020 · 1 comment

Comments

@grondo
Copy link
Contributor

grondo commented Mar 2, 2020

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.

@garlick
Copy link
Member

garlick commented Mar 2, 2020

That all sounds sensible, so count me in with that guidance.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants