Policy on Tools Posting

[Andrew Geissler]

On Mon, Aug 12, 2019 at 7:58 PM Wilfred Smith <wilfredsmith at fb.com> wrote:
>
>
> 1. Are there guidelines/procedures specific to submitting command line tools and utilities? I have heard that there may be a repository and/or path dedicated to CLI tools.

The community has definitely tended to limit wrapper tools within
OpenBMC. We had a discussion a while back that we're open to some but
the API's to them really need to be thought out and reviewed because
command line tools become customer API's (i.e. people start writing
scripts on top of these tools that then become key to the
manufacturing process or some other critical area).

Anything that goes into OpenBMC needs to support OpenBMC interfaces.
For example, I'm not familiar with fruid-util's D-bus service
xyz.openbmc_project.FruDevice. A "busctl tree
xyz.openbmc_project.Inventory.Manager | cat" shows the inventory items
on OpenBMC.

One issue we have within OpenBMC is there may be different
implementations of the D-bus API's for a given area. For example,
Inventory has different implementations so I'm not sure which repo
would best fit your tool. That type of issue leads me to wonder if we
should put the tools with the interface definitions in
openbmc/phosphor-dbus-interfaces? Or maybe a separate phosphor-tools
repo would be more logical for these.

Either way, I think command line tools should each get their own
mini-design doc
(https://github.com/openbmc/docs/blob/master/designs/design-template.md)
with requirements and interfaces clearly defined for review by the
community. If we can find a generic tool that multiple people find
useful, we can then find a place to put it. Otherwise, you could host
your tools outside of openbmc/ github and just pull them into recipes
from within your meta-facebook layer.

> Thanks in advance,
>
> Wilfred