<html><body><a target="_blank" href="https://lists.ozlabs.org/listinfo/openbmc<br"><br>
Date: Wed, 19 Sep 2018 09:42:16 -0700<br>
From: Patrick Venture <venture@google.com><br>
To: anoo@linux.ibm.com<br>
Cc: OpenBMC Maillist <openbmc@lists.ozlabs.org>, Brad Bishop<br>
<bradleyb@fuzziesquirrel.com>, Nancy Yuen <yuenn@google.com>,<br>
openbmc-bounces+anoo=linux.ibm.com@lists.ozlabs.org<br>
Subject: Re: Repository Growth<br>
Message-ID:<br>
<CAO=notwvBca4ANU6b-kQggP53cM2CdsCVV5QqsBYUCJ_jB+Xkg@mail.gmail.com><br>
Content-Type: text/plain; charset="UTF-8"<br>
<br>
On Wed, Sep 19, 2018 at 9:03 AM Adriana Kobylak <anoo@linux.ibm.com> wrote:<br>
><br>
> On 2018-09-19 10:47, Patrick Venture wrote:<br>
> > With the growth of number of repositories, it might be overwhelming to<br>
> > someone who wants to set things up.<br>
> ><br>
> > I'd like to write up a directory that groups the repositories by<br>
> > purpose. I wasn't sure if this made sense, so I wanted early feedback<br>
> > before I started. The maintenance of it would be horrible for one<br>
> > person, but if someone wants their repository to have details and so<br>
> > on they can add it.<br>
> ><br>
> > I think it's important or useful to know what's out there and how<br>
> > things work together or don't, and what options there are for<br>
> > developers.<br>
> ><br>
><br>
> +1 . Do you have a template in mind on how this could look like?<br>
<br>
I've been toying around with some ideas on how to organize the<br>
information. Grouping the subtrees together is a no-brainer, but many<br>
daemons don't really fit into a category. Maybe that's fine, maybe<br>
then it'd be uncategorized.<br>
<br>
I was imagining:<br>
<br>
{repository name}<br>
{short description}<br>
works with: {list of related pieces}<br>
<br>
for instance:<br>
"""<br>
### phosphor-hwmon<br>
phosphor-hwmon periodically reads and reports hwmon sensor values to dbus.<br>
works with: phosphor-host-ipmid<br>
"""<br>
<br>
You don't need to run phosphor-host-ipmid to use phosphor-hwmon, and<br>
phosphor-pid-control and other daemons can also listen to sensor<br>
values or read them over dbus, so I don't know how complete such a<br>
list would need to be. So maybe the list should be less explicit. I<br>
realize that the recipes themselves reveal the true dependencies,<br>
either virtual or specific and I don't want to repost information. I<br>
just want to present a better interface to the set of repositories and<br>
how they work together (or don't) than github has.<br>
<br>
><br></a><div><a target="_blank" href="https://lists.ozlabs.org/listinfo/openbmc<br">
> > Thoughts?</a></div><div><br></div><div>I had the same idea from reading through the presentations recently linked to on this mailing list.<br></div><div><br>OpenBMC lists its features on its front page (https://github.com/openbmc/openbmc README) and suggests there is more information in https://github.com/openbmc/docs. However, the information is not structured as well as it could be for someone to learn about each feature. I propose to list each feature along with the following information (as applicable):<br> - reference an external website or standard<br> - categorize: host-facing, management network facing, application<br> - explain terminology (give synonyms)<br> - explain 1 or 2 use cases<br> - link to the docs (which should explain customizations)<br> - link to the source code repo<br><br>I would start with the features listed in openbmc/README, and add features (or interfaces?) from James's presentation:<br> - Host interfaces: KCS, BT, mbox, IPMB, USB, VGA<br> - Network Interfaces: Redfish, https, ssh, rmcp+<br> - Applications: EWS, KVM, IPMI, FSC, SEL, SOL, Chassis Control, ASD, Firmware Update, Configuration Manager, Sensor Monitor<br><br>So, the proposal is to group repos by feature and interface.<br></div><div><br></div><a target="_blank" href="https://lists.ozlabs.org/listinfo/openbmc<br">
> ><br>
> > Patrick<br>
><br>
</a><a target="_blank" href="https://gerrit.openbmc-project.xyz/#/q/project:openbmc/meta-x86<br"><br></a></body></html>