How to submit a patch to ModemManager?

[Aleksander Morgado]

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