Repository Growth

[Andrew Geissler]

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

Makes sense to me.

Per the mailing list discussion yesterday on the hackathon, I'm also
starting to work on some "digging into openbmc coding" type docs.
That will probably deserve it's own directory?
- Getting Started: Dev env setup, hello world via SDK/QEMU, adding a
new system/layer, customizing webui and other items for new system,
bitbake using local repos, ...

>
> So, the proposal is to group repos by feature and interface.
>
> > >
> > > Patrick
> >
>