Having worked on the kernel for decades, and imposing a lot of the same code/git hygiene for liburing, there can be a disconnect for contributors on what is expected of a commit and commit message, and what series of commits should look like. I attempted to provide a basic guideline here:
https://github.com/axboe/liburing/blob/master/CONTRIBUTING.md
and would appreciate feedback from folks on what I missed, what isn't clear, etc.
=> More informations about this toot | More toots from axboe@fosstodon.org
@axboe do you have any strategy for ensuring bisectability while also being on GitHub? A quick look at your workflow shows it does not build&test every commit, only PRs. Do you do that yourself locally?
=> More informations about this toot | More toots from Aissen@treehouse.systems
@Aissen @axboe the paragraph about coding style leaves me with a vague appeal. What does this really mean? Do you have a .clang-format file I can use to bring my code into shape? What else do you mean with coding style? Something beyond formatting and variable naming conventions?
=> More informations about this toot | More toots from markuswerle@nrw.social
@Aissen @axboe sed -e’s/should/must/g’ and then check if the advice given is sufficient to adhere to the rules.
=> More informations about this toot | More toots from markuswerle@nrw.social
@Aissen @axboe replace “it's not uncommon to have a pull request contain multiple commits” by “it's perfectly OK to have a pull request contain multiple commits” to avoid the double negation that let me misread it first and also sounds more positive.
=> More informations about this toot | More toots from markuswerle@nrw.social
@Aissen @axboe for “squash fixup” please give an example of what you really want to happen. Do you want a git amend for the wrong commit or a local history rewrite pushed? 3 lines of git commands remove all room for interpretation.
=> More informations about this toot | More toots from markuswerle@nrw.social
@Aissen @axboe I forgive you the “Don't explain what the code in commit does, that should be readily apparent from just reading the code.“ You are a very intelligent kernel hacker so I fully understand that “just read the code” is an explanation for you. In my world I want a high level explanation of what was intended. But I am a stupid slow learner and cannot grok Linux source code. I only see trees, not the woods.
=> More informations about this toot | More toots from markuswerle@nrw.social
@Aissen @axboe do we need “heinous” in
“liburing doesn't squash-on-rebase, or other heinous practices sometimes seen elsewhere.”?
For merge/rebase strategies I would go with YMMV.
=> More informations about this toot | More toots from markuswerle@nrw.social
@Aissen @axboe That’s my 2 cents. In general a good thing to have that document.
=> More informations about this toot | More toots from markuswerle@nrw.social
@markuswerle @Aissen No we definitely don't, it's an attempt at humor. But squash or rebase on merge is heinous, objectively, so I'll keep it ;-)
=> More informations about this toot | More toots from axboe@fosstodon.org
@axboe @Aissen ROFL
=> More informations about this toot | More toots from markuswerle@nrw.social This content has been proxied by September (ba2dc).Proxy Information
text/gemini