mirror of
https://source.denx.de/u-boot/u-boot.git
synced 2026-06-02 09:46:37 +03:00
7c419d4b57
Our official domain is now u-boot-project.org, so update all in-tree references to use the correct domain. Reviewed-by: Tony Dinh <mibodhi@gmail.com> Reviewed-by: Peter Robinson <pbrobinson@gmail.com> Signed-off-by: Tom Rini <trini@konsulko.com>
77 lines
3.1 KiB
ReStructuredText
77 lines
3.1 KiB
ReStructuredText
.. SPDX-License-Identifier: GPL-2.0+
|
|
.. sectionauthor:: Peter Robinson <pbrobinson@gmail.com>
|
|
|
|
Contributing
|
|
============
|
|
|
|
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-project.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.
|