X-Git-Url: https://git.ozlabs.org/?p=petitboot;a=blobdiff_plain;f=doc%2Fdev%2Fsubmitting.rst;fp=doc%2Fdev%2Fsubmitting.rst;h=fb968cda1e288bb6225695590f8e42f8250aa07a;hp=0000000000000000000000000000000000000000;hb=d61806e79788d996581311d2eb25bc043c37435a;hpb=cf9e0cd6f7caf7b171457f7bf9f56f23ec3e478c diff --git a/doc/dev/submitting.rst b/doc/dev/submitting.rst new file mode 100644 index 0000000..fb968cd --- /dev/null +++ b/doc/dev/submitting.rst @@ -0,0 +1,26 @@ +Development and Submitting Patches +================================== + +Petitboot is largely written in C and follows the `Linux kernel coding style `_. + +Development occurs on the `Petitboot mailing list `_. + +Petitboot also has a `Patchwork instance `_ that watches the list. + +Patch Guidelines +---------------- + +Patches should be sent to the mailing list generally following what you would see in `submitting-patches `_ + +In general if you generate the patch with ``git format-patch`` or ``git send-email`` you should be fine. + +Patches should have an obvious title and where necessary a clear commit message describing the changes. +Avoid lumping unrelated changes together, instead putting them in separate patches in a logical order. +If a patch is generally contained to one area (and it should be), it should generally be prefixed with the path of what it is changing, for example "discover/grub:" or "ui/ncurses:". + +If sending a new revision of a patch update the title to mention the verson (hint: ``git format-patch -v 2``) and include a short changelog under the ``---`` describing what changed between versions. Check out the list archives for `some examples `_. + +Stable Patches +-------------- + +Patches or upstream commits that need to be applied to a stable branch should be restricted to small, self-contained fixes as much as possible. Avoid backporting new features or invasive changes.