1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
|
.. SPDX-License-Identifier: GPL-2.0+
.. sectionauthor:: Peter Robinson <pbrobinson@gmail.com>
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.
|
