<div dir="ltr"><br><div class="gmail_extra"><br><div class="gmail_quote">On Thu, Feb 2, 2017 at 3:21 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"><span class="">On Fri, Feb 3, 2017 at 3:13 AM, Rick Altherr <<a href="mailto:raltherr@google.com">raltherr@google.com</a>> wrote:<br>
> Thank you for putting this together.  I find it really helpful to have an<br>
> explicit process to follow.  I do have a few questions:<br>
> - What do we do about patches that require functionality that is not<br>
> currently available upstream (for instance, a subsystem change is being<br>
> reviewed by upstream but isn't yet merged).  Can that patch be sent to<br>
> OpenBMC only or must we wait for upstream to decide on the dependent patch?<br>
<br>
</span>I couldn't grok what you're describing here.<br>
<br>
If there's an upstream change under debate that your driver depends<br>
on, we can pull it in.<br>
<span class=""><br></span></blockquote><div><br></div><div>That's what I was asking.  Thank you for clarifying.</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><span class="">
> - OpenBMC and upstream will inevitably diverge between OpenBMC rebases.<br>
> When upstream has changed in a significant way (say the recent hwmon API<br>
> changes), what do we do?  Do we send a new patch of equivalent functionality<br>
> to OpenBMC?  Do we ask for patches to be cherry-picked from upstream?<br>
<br>
</span>This is when a developer has created a driver against upstream, and<br>
the APIs are not the same as present in the OpenBMC tree? We should<br>
take the option that requires the least amount of work.<br>
<br>
We should backport API changes when it doesn't break other drivers<br>
(when APIs are being added). When APIs are being significantly<br>
modified, it may be easier to backport the driver.<br>
<span class=""><br></span></blockquote><div><br></div><div>SGTM.</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><span class="">
> - Which branch is the authoritative branch for basing patches on for<br>
> OpenBMC?<br>
<br>
</span>I will publish this on the wiki. For the upcoming cycle, we will move<br>
to a v4.9 based branch next week. I will call for patches to be sent<br>
against this tree once it's published.<br>
<br></blockquote><div><br></div><div>I'll wait for that to happen before sending my ADC driver.</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
Thanks for taking a read and the questions. If you want more detail let me know.<br>
<br>
Cheers,<br>
<br>
Joel<br>
<div class="HOEnZb"><div class="h5"><br>
><br>
> On Wed, Feb 1, 2017 at 9:14 PM, Joel Stanley <<a href="mailto:joel@jms.id.au">joel@jms.id.au</a>> wrote:<br>
>><br>
>> 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<br>
>> 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<br>
>> 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<br>
>> 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>
><br>
><br>
</div></div></blockquote></div><br></div></div>