Policy on Tools Posting

[Andrew Geissler]

On Thu, Aug 15, 2019 at 4:57 PM Wilfred Smith <wilfredsmith at fb.com> wrote:
>
> My manager (Sai) is asking whether there is precedence for having utilities posted outside the OpenBMC repository. Do we want 100 OpenBMC tools repositories, each managed differently or 1 harmonized repository?

We do bring in some tools, like for our openpower systems we bring in a pdbg
tool[1]. That tool isn't really specific to OpenBMC though, just a
useful tool that
works within OpenBMC.

The spirit behind creating https://github.com/openbmc/openbmc-tools was to
not have a bunch of the same tools being written by a bunch of different
people. So far it's only been tools run outside of OpenBMC though. I know
AndrewJ mentioned he may be open to using that repo for what's proposed here.
It seems like a better fit then making some other tools repo. To me that's just
confusing when you go to a github project and see multiple repositories with
"tools" in the name.

[1]: https://github.com/openbmc/openbmc/blob/master/meta-openpower/recipes-bsp/pdbg/pdbg_2.2.bb

> Separately, is there any effort to create a “common core” for OpenBMC such that an effort akin to POSIX or the Single UNIX Specification isn’t needed ten years from now? Without standard API (or at least abstracted tools) for things like where FRU information is located or sending IPMB commands, isn’t the market for innovative software stifled (Android software market vs iOS, or even Linux vs Windows)?

Our focus so far has been on standardizing our external interfaces,
i.e. Redfish/IPMI.
There has not been much focus on the internals (i.e. ssh) because it's a lot
of work to version and standardize something and it's not something people
buying OpenBMC machines are very interested in. I think wrapper tools are our
best bet but there's been a lot of back and forth on that as well.

> Wilfred
>