<div dir="ltr">Thank you for putting this together. I find it really helpful to have an explicit process to follow. I do have a few questions:<div>- What do we do about patches that require functionality that is not currently available upstream (for instance, a subsystem change is being reviewed by upstream but isn't yet merged). Can that patch be sent to OpenBMC only or must we wait for upstream to decide on the dependent patch?</div><div>- OpenBMC and upstream will inevitably diverge between OpenBMC rebases. When upstream has changed in a significant way (say the recent hwmon API changes), what do we do? Do we send a new patch of equivalent functionality to OpenBMC? Do we ask for patches to be cherry-picked from upstream?</div><div>- Which branch is the authoritative branch for basing patches on for OpenBMC?</div></div><div class="gmail_extra"><br><div class="gmail_quote">On Wed, Feb 1, 2017 at 9:14 PM, Joel Stanley <span dir="ltr"><<a href="mailto:joel@jms.id.au" target="_blank">joel@jms.id.au</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Hello OpenBMCers,<br>
<br>
Over the past few days I've been chatting with some of the people<br>
involved in kernel development for this project. We've looked at ways<br>
to make this a better experience for new developers, those overseeing<br>
development, and folks wanting to ship products on deadlines.<br>
<br>
With Jeremy's help we've drafted a proposal that hopes to take<br>
everyone's needs into account. Please have a read and reply with your<br>
feedback. The draft of the process is also on the OpenBMC wiki at<br>
<a href="https://github.com/openbmc/linux/wiki/DevelopmentProcess" rel="noreferrer" target="_blank">https://github.com/openbmc/<wbr>linux/wiki/DevelopmentProcess</a><br>
<br>
## Upstream is key<br>
<br>
In order to leverage the benefits of using the Linux kernel, OpenBMC<br>
maintains a policy that all kernel code will be merged upstream.<br>
<br>
However, there are often cases where product requirements mean that<br>
synchronising with an upstream schedule is not always possible. This<br>
process aims to allow both goals (upstream inclusion and a useful<br>
OpenBMC build) to occur in parallel.<br>
<br>
## Pre-upstream inclusion plans<br>
<br>
The project has a process for including patches before they are merged<br>
upstream in order to allow development and testing before the upstream<br>
work is complete.<br>
<br>
Patches for pre-upstream inclusion in the OpenBMC kernel should at<br>
least be of a level approximately ready to submit upstream. Although<br>
this is somewhat subjective, this will almost always be indicated by:<br>
<br>
- passing the 'checkpatch' utility without warnings<br>
<br>
- the patch should not break the build for the kernel configurations<br>
that are currently in use, nor should it introduce compiler warnings<br>
<br>
- a kernel including the patch should be boot-tested in the qemu environment<br>
<br>
Non-upstreamed patches will be carried in the OpenBMC kernel until the<br>
upstream stable release that occurs 30 days after original patch<br>
inclusion. With a rough maximum time of 14 days between stable<br>
updates, this means that the changes will be carried for 30-44 days.<br>
<br>
However, work doesn't end here: during this time, the patch submitter<br>
should keep interacting with the community to get the patch included<br>
in the upstream kernel.<br>
<br>
After the 30-day cycle, the patch will typically be on its way through<br>
the upstream process. It is the patch owner's responsibility to ensure<br>
that this proceeds. Once the patch has been included in an upstream<br>
tree, we will switch over to the upstreamed patch. The OpenBMC kernel<br>
maintainers will take responsibility for carrying that patch until a<br>
subsequent update moves to a base version that includes the upstream<br>
change.<br>
<br>
However, if a patch is still not included by that time, it *may* be<br>
resubmitted for inclusion in the next 30-day cycle. This is<br>
conditional on at least one new revision being sent upstream for<br>
further review, demonstrating that the owner is making progress on<br>
upstream inclusion. In order to indicate that the patch should be<br>
carried over, the patch owner should re-submit it to the mailing list,<br>
with details of upstream progression so far.<br>
<br>
At this point, the patch owner should be in contact with the OpenBMC<br>
kernel maintainers via either the mailing list, or #openbmc IRC<br>
channel, for assistance with the upstreaming process.<br>
<br>
In situations where the upstream acceptance is taking longer than<br>
expected, we can repeat the cycle above, for a maximum of three<br>
iterations (ie, three 30-day periods).<br>
<br>
After those three periods, the patch will be dropped from the tree.<br>
<br>
Note that this process is not a "free ticket" to 90 days of inclusion<br>
in the tree. The kernel maintainer has the responsibility to ensure<br>
that the code is of sufficient quality for the multiple consumers of<br>
the OpenBMC kernel, and may reject submissions on serious grounds if<br>
necessary (eg, security issues, major code review issues, copyright<br>
concerns, adversely affecting other platforms). The intention here is<br>
to facilitate collaboration on the kernel and scale development across<br>
OpenBMC contributors.<br>
<br>
## Platform scaling<br>
<br>
A consequence of the process above is that we will be including<br>
patches that affect platforms that the OpenBMC kernel team does not<br>
necessarily have access to, without outside code review. This means we<br>
have no way to test those patches.<br>
<br>
To prevent failures from these carried patches, owners of the patches<br>
will be added as code reviewers on the OpenBMC yocto updates.<br>
<br>
We expect these owners to test that the updated kernel still carries<br>
the required functionality, and provide code review feedback if not.<br>
This will prevent the OpenBMC system from being updated to a kernel<br>
which breaks pre-upstream support for vendor-specific functions.<br>
<br>
If no feedback is provided with one week, is it assumed that the<br>
update is OK to proceed. Regardless, a positive code review is still<br>
useful, to provide quicker feedback.<br>
<br>
# Processes<br>
<br>
## Patch submitters (wishing to have a change included through this process)<br>
<br>
- ensure that patches conform to base-level quality guidelines<br>
- no warnings from checkpatch<br>
- does not introduce errors or warnings, for specific defconfigs<br>
- aspeed_g4_defconfig<br>
- aspeed_g5_defconfig<br>
- boot test the kernel using the qemu simulation environment<br>
- At a minimum, the system should boot to a userspace prompt of<br>
the OpenBMC userspace<br>
- submit upstream first<br>
- submit proposed patches to <a href="mailto:openbmc@lists.ozlabs.org">openbmc@lists.ozlabs.org</a><br>
- This version of hte patch should contain "[PATCH linux<br>
<branch>]" in the subject, where <branch> is the name of the current<br>
OpenBMC development tree<br>
- continue with upstream discusions, by promptly following-up with<br>
code review feedback, and post new versions of code regularly<br>
- if the 30-day expiry date is approaching, re-send to<br>
<a href="mailto:openbmc@lists.ozlabs.org">openbmc@lists.ozlabs.org</a>, requesting re-inclusion in the tree, with<br>
details of upstream work so far (just a short sentence in the patch<br>
email should be sufficient for this)<br>
- monitor gerrit review queue for test requests from OpenBMC kernel maintainer<br>
<br>
## OpenBMC kernel maintainer<br>
<br>
- Review patches submitted to the openbmc list<br>
- Merge patches into the OpenBMC tree<br>
- Rebase the OpenBMC tree at the agreed interval (30 days)<br>
- Announce the merge window on the mailing list<br>
- Update to the latest stable upstream release<br>
- Apply patches from the list<br>
- Update the status documentation for pre-upstream patches<br>
- Test kernel on available platforms<br>
- Palmetto, Witherspoon<br>
- Qemu Palmetto, Qemu Romulus<br>
- Add relevant reviewers for gerrit openbmc yocto "kernel bump" changes<br>
<br>
## All developers<br>
<br>
- Review patches on the openbmc list<br>
- Exceed RDI of vegemite<br>
<br>
## Project management<br>
<br>
- regularly check the status page, to ensure that:<br>
- patches required for your project are not at risk of exipiring<br>
- upstreaming efforts are not falling behind schedule<br>
</blockquote></div><br></div>