Hello to OpenBMC Team

[Verdun, Jean-Marie]

Hi Brad,

I realize that we are not in the best condition. We faced multiple challenges before being able to arrive to such stage. The first one is a chicken and egg issue, related to the need to create some momentum inside HPE to be able to start working on a project like OpenBMC. To reach it we had to create a Proof of Concept, which needed that we worked on our GXP asic support and introduce patches into the original source tree that we forked. At the PoC level, we still could have ended up into a situation where we would have dropped the work.

We used that PoC to demonstrate the value of OpenBMC on top of our hardware to public and private customers, leading to a green light to join the project. 

I know very well the pain to maintain a fork of a project, and I believe most of the HPE team also. We will work pretty hard at the early stage of the project to upstream what is needed just to be sure that we do not end up into a complex situation. My ideal goal is always to commit upstream instead into a fork, and I share your concerns. We will probably have a rollercoaster ride at the beginning due to the amount of code to introduce, but we are ready to adapt to the community needs.

I do contribute to other projects like FreeCAD, which are huge piece of code, and maintain the snap of it. So forking is never a good idea, except if you want to build a separate project, which is clearly not our intend ! We want to be part of this community, and make its software works properly on our systems.

We do have an alpha loan program which will start soon also, and we would like to support it "publicaly" allowing its members to rebuild openbmc and linuxboot image from code which are available on github, this also explain the tight schedule we follow.

Last but not least, I am trying to automatize as much as we can, build and testing on HPE hardware through our public interactive CI which is under active development. The tool intend to take as an input a github repo, a branch and build a functional openbmc/linuxboot image as an output which will be automatically ran on a live hardware machine. It is available on https://osfci.tech and https://github.com/hewlettpackard/osfci. The code is still a lot buggy, but I am progressing on a daily basis.

One of the main advantage of it, is that you do not need to be seated closed to real hardware to test on real hardware. I have also included a build machine with a lot of core and memory, so we could batch build images. If needed we could try to find a way to share it as a build systems into OpenBMC Jenkins.

By the way Brad, do you think we could create a meta-hpe into the tree ?

vejmarie

On 6/4/20, 10:59 AM, "openbmc on behalf of Brad Bishop" <openbmc-bounces+jean-marie.verdun=hpe.com at lists.ozlabs.org on behalf of bradleyb at fuzziesquirrel.com> wrote:

    On Wed, 2020-06-03 at 19:36 +0000, Garrett, Mike (HPE Server Firmware)
    wrote:
    > Hi Brad,
    > 
    > Our thinking is to set up public forks "close to home" that we can
    > work rapidly in 

    That makes sense - my dream is that someday everyone could work rapidly
    directly in upstream.  We have work to do to get there for sure.    If
    ideas come up that could make the situation better please share them
    here on the list.

    I think it works best for everyone involved when you can commit to
    working directly upstream, first.  My observation is that it is
    extremely difficult to circle back and incorporate community feedback
    after you have something that works for you.  That can lead to problems
    like the code not being accepted or introducing fragmentation into the
    project.

    But I understand that can be really hard and conflicting internal
    business pressures are often mitigated with techniques like the one you
    have described.  My company maintains forks too.

    One last opine just in case its helpful - like security, working in
    upstream first isn't boolean - it is a spectrum.  Where an organization
    (or a single developer) lands on that spectrum is one element of what
    separates those with influence over others from those without.

    > and simultaneously work to upstream patches for U-boot, Linux, and
    > OpenBMC to the main repos.  

    Great!  Looking forward to working with you and the team on that.

    thx -brad