Policy on Tools Posting

[Vijay Khemka]

On 8/15/19, 5:59 AM, "openbmc on behalf of Andrew Geissler" <openbmc-bounces+vijaykhemka=fb.com at lists.ozlabs.org on behalf of geissonator at gmail.com> wrote:

    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.
Andrew, I like the idea of having phosphor-tools which can be a placeholder 
for any commandline tools and can grow as per requirement. Currently
it can start with 3 proposed tools. 

    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)
Wilfred, Can you please create a document as per this design template and submit for review.

    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