Proposing changes to the OpenBMC tree (to make upstreaming easier)

[Brad Bishop]

On Mon, May 23, 2022 at 02:07:55PM -0700, John Broadbent wrote:

>>  "I have no interest in making this easier for you (if it is worse in
>other ways for the project)."   - referring to downstream only features.

>This is the wrong way to view features the community does not want, 

Can you talk about what features the community does not want?  If I pick 
on Google a little bit there is already a google-misc repo where Google 
puts whatever features it wants.  There is the meta-google layer that 
doesn't actually have any platforms in it.  There is the newly approved 
Google SMM logging feature/repo.  There is an OEM Google REST API in 
upstream bmcweb.  There are multiple Google OEM IPMI repositories.  And 
to be fair, Google isn't alone here - IBM has an API in bmcweb and 
layers without platforms too.  Where is the external (community) push 
back on features?  The only one I am aware of is a feature IBM wanted to 
contribute (which for the record, I am not convinced rejecting it was 
appropriate):
https://lore.kernel.org/openbmc/CAMhqiMoFAHcUk0nO_xoOubcZqF_dPDFweqsttTULRJK38o1Ung@mail.gmail.com/

My point is, I am having trouble accepting that community pushback is 
what causes downstream patches.

> and features we would not be allowed to share. 

This I can accept as a generator of downstream patches.  I actually 
support the monorepo concept for the most part, but not with this as 
motivation.  If IBM's pay-for-access feature (reference the thread I 
linked above if that doesn't make sense) was counter to the spirit of 
open source (again, I don't think it is), adding this kind of thinking 
to our decision process is even more counter.

>There is a layer of complexity
>that we use to integrate with our data centers services that only we need.
>A better model would allow openbmc to be flexible enough to enable
>downstream features.

And an even better model would be one where there is a path to getting 
all features upstream?