Public forks (Re: PECI patchset status)

krtaylor kurt.r.taylor at gmail.com
Wed Sep 9 03:24:32 AEST 2020


On 9/3/20 12:15 PM, Vernon Mauery wrote:
> On 03-Sep-2020 10:27 AM, Patrick Williams wrote:
>> On Thu, Sep 03, 2020 at 05:57:48AM +0000, Mihm, James wrote:
>>> Thank you Joel for carrying this patchset, and Intel does have an 
>>> interest in getting our patchsets upstreamed.
>>>
>>> Since Intel has a large set of patches that need to be upstreamed our 
>>> plan is to fork the kernel in github/intel-bmc and apply the intel 
>>> patchsets. Upstream recipes can then pull the kernel from the intel 
>>> fork with the intel patches. Intel will ensure that this fork tracks 
>>> the openbmc kernel version and maintain the intel patchsets while in 
>>> the process of getting them upstreamed.
>>
>> Rather than create a separate fork of the kernel, is there something
>> that could be done here to have someone from Intel work with Joel on
>> preparing the patches?  When a new kernel comes out, Joel can ensure it
>> works on the base AST2xxx system design and before we move all the
>> systems to it, someone from Intel can rebase the non-upstreamed patches
>> they are carrying?  This hopefully reduces some of the burden on Joel
>> and stops us from further fragmenting the community.
> 
> Keep in mind that Intel does not plan to keep the fork around 
> indefinitely. The hope is to fully upstream all of the patches that we 
> have outstanding. Our intention is not to fragment the community, but to 
> provide a mechanism to continue to move forward while still providing a 
> way for other users to build the intel-platforms target.


In 20+ years of open source development I have never seen a fork like 
this actually improve anything for anyone involved.

It fragments the community and winds up being a PITA for the company 
that forked since they now have to figure out how to reconcile the two 
trees.

As I said from day one with this fork, if there is a problem with the 
speed of the community ("moving forward"), then the problem is probably 
with planning and transparency. If we are not talking about n+1 release 
features, then it is already too late.

Open source really does work, it starts with an commitment from everyone 
to look out for the community first.

All IMHO,
Kurt Taylor (krtaylor)

> As an added feature, having our full kernel source in a publicly 
> available tree will allow us to upstream more features that depend on 
> kernel support that is not currently available.
> 
> --Vernon



More information about the openbmc mailing list