Hey Elias, > > I would like to submit a patch to fix this issue: > > https://gitlab.freedesktop.org/mobile-broadband/ModemManager/-/issues/257 > > Are there some rules or recommendations about how to submit a patch to > ModemManager, like rules for coding style and/or what commit messages > should look like, if everything should be squashed to a single commit, > things like that? >
There's nothing written, we should do that at some point... Here's some suggestions: * Regarding coding style, the best thing to do is read code on the same file you're modifying, and get a feel of how the code is formatted. E.g. indent and align with 4 spaces, check position of braces in conditionals, ensure a whitespace is always given before any kind of open-parenthesis, and so on. The code you write should "fit" visually around the other code that exists. This suggestion is applicable to any kind of FOSS contribution you do; just adapt yourself to the coding style of the project you're patching. And having the coding style right is key so that the maintainers do a proper review; when we review we want to review the logic being changed, not the coding style :) * Commit messages should look like "<module>: short explanation" in the first line (max 70 chars is suggested) and then one empty whiteline and then the body of the message explaining with more detail, if needed, the change done. Again, the best way to see what the commit message should look like is to run "git log" in the git checkout. Your commit message should "fit" with the already existing ones. * Regarding whether commit should be squashed or not; two key things to consider. First, each commit should be self-contained logically; i.e. a commit changing for example the huawei plugin to add a URC handler should not have also a totally unrelated change in the generic implementation. Each commit should be able to speak for itself, and while reviewing we'll review all commits one by one, starting from the first up to the last one. And second key thing, each commit should be able to allow a clean build of the project; you shouldn't break the build in one commit and fix it later in another one. You can enforce this second thing with e.g. "git rebase -i origin/master --exec make", that will go one by one over all the commits in your branch and running make. I'll try to cleanup all this in a document to publish on the website. -- Aleksander https://aleksander.es _______________________________________________ ModemManager-devel mailing list [email protected] https://lists.freedesktop.org/mailman/listinfo/modemmanager-devel
