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

John Broadbent jebr at google.com
Tue May 24 13:54:06 AEST 2022


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

Could you give me some insight on that? Why does that surprise you?

I don't want to call out any concrete examples without talking to the
change owner first.
(I don't want to put them on 'blast')

But we can glance at my work.
https://gerrit.openbmc.org/c/openbmc/bmcweb/+/53563/8
https://gerrit.openbmc.org/c/openbmc/bmcweb/+/53325

I have been trying to get these two changes in for the last 19
calendar days. If it gets heldup by
https://gerrit.openbmc.org/c/openbmc/phosphor-dbus-interfaces/+/53676.
I might have to patch to make my deadline.

The ask in PDI will take real time to negotiate, maybe months (as the last
attempt took 5 months, and still failed)
My schedule says I had 3 weeks to make this change?

Again, would rather not talk about others patches, but if you have insight
please feel free to join in.

Thanks



On Mon, May 23, 2022 at 4:48 PM Brad Bishop <bradleyb at fuzziesquirrel.com>
wrote:

> 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?
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.ozlabs.org/pipermail/openbmc/attachments/20220523/b202f82b/attachment.htm>


More information about the openbmc mailing list