diff options
Diffstat (limited to 'doc/CONTRIBUTE.rst')
| -rw-r--r-- | doc/CONTRIBUTE.rst | 76 |
1 files changed, 76 insertions, 0 deletions
diff --git a/doc/CONTRIBUTE.rst b/doc/CONTRIBUTE.rst new file mode 100644 index 00000000000..8ccb3a193da --- /dev/null +++ b/doc/CONTRIBUTE.rst @@ -0,0 +1,76 @@ +.. SPDX-License-Identifier: GPL-2.0+ +.. sectionauthor:: Peter Robinson <[email protected]> + +Overview +-------- + +This document is a high level contributors overview setting overall expectations, +so people can get started quickly, the rest of the documentation goes into the +details. + +Code of Conduct +--------------- + +The U-Boot project doesn't currently have an explicit code of conduct, but all +contributors are expected to act cordially to, and be respectful of, each other's +contributions and opinions. There are many code of conducts for open source +projects available to review if you are unsure of expectations. + +Repository +---------- + +The official U-Boot repository is located at https://source.denx.de/u-boot/u-boot + +Further more detailed documentation can be found at the following link: +https://docs.u-boot.org/en/latest/index.html + +Contributions +------------- + +Contributions to the project are welcome. The U-Boot project uses a fairly +traditional Linux style development work-flow using git and `a mailing list +<https://lists.denx.de/listinfo/u-boot>`_. + +Patches should be sent to the mailing list using ``git send-email`` or the +equivalent commands using ``b4`` or ``patman`` with appropriate sign-off and +attributions for the code in question. Maintainers should be copied on mails +and they can be found with the ``./scripts/get_maintainer.pl 0001-fix.patch`` +script. Please don't send patches as attachments, and ensure corporate mail +systems don't reformat patches, append disclaimers or other unnecessary notes. +The b4 tool automates a number of components mentioned above. + +Patch Series +------------ + +Patch series for a specific subject are welcome but they should be constrained +to a single topic with a cover letter outlining the intention of the series. +Each patch within the series should cover a single change, be self contained, +not break the build or cause a regression. + +Generally bug fixes for existing bugs should be at the beginning of the +series before any enhancements to allow those patches to be picked up early. + +Each iteration of a patch set should be versioned, allow enough time for people +to review previous versions of the series and incorporate all the review +feedback before sending a new version. A week between larger patch sets is +considered as reasonable amount of time. + +Development Branches +-------------------- + +The U-Boot developers use two main branches for developing the code. The master +branch is used for the current development cycle, while there is also a next +branch intended to land changes for the next release early to enable wider +testing of larger code changes. The next branch is merged to master shortly +after the tagging of a new major release. + +Similar to Linux there is a three week merge window post release after which a +release candidate is tagged. There's typically a new release candidate every +two weeks post merge window until the stable generally available release. + +Release Schedule +---------------- + +There is currently four major releases a year in January (.01), April (.04), +July (.07) and October (.10). These typically happen on the first Monday of +that month. There is currently no release branches or long term releases. |