RE: Repository Growth

RE: Repository Growth

[joseph-reynolds]

[-- Attachment #1: Type: text/plain, Size: 1175 bytes --]

 > 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

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



[-- Attachment #2: Type: text/html, Size: 4430 bytes --]

Re: Repository Growth

[Andrew Geissler]

On Wed, Sep 19, 2018 at 12:56 PM <joseph-reynolds@charter.net> wrote:
>
>
> Date: Wed, 19 Sep 2018 09:42:16 -0700
> From: Patrick Venture <venture@google.com>
> To: anoo@linux.ibm.com
> Cc: OpenBMC Maillist <openbmc@lists.ozlabs.org>, Brad Bishop
> <bradleyb@fuzziesquirrel.com>, Nancy Yuen <yuenn@google.com>,
> openbmc-bounces+anoo=linux.ibm.com@lists.ozlabs.org
> Subject: Re: Repository Growth
> Message-ID:
> <CAO=notwvBca4ANU6b-kQggP53cM2CdsCVV5QqsBYUCJ_jB+Xkg@mail.gmail.com>
> Content-Type: text/plain; charset="UTF-8"
>
> On Wed, Sep 19, 2018 at 9:03 AM Adriana Kobylak <anoo@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
> >
>

Re: Repository Growth

[Bills, Jason M]

>>>> 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.
>>>>

Is it possible to scrape some of this info from github, gerrit, etc.? 
Perhaps portions of this could be automated to help with maintenance and 
to keep the information up-to-date.

Re: Repository Growth

[Nancy Yuen]

[-- Attachment #1: Type: text/plain, Size: 565 bytes --]

+1, I like the idea of having some form of automation to help with the
maintenance of this information.

----------
Nancy

On Wed, Sep 19, 2018 at 11:45 AM, Bills, Jason M <
jason.m.bills@linux.intel.com> wrote:

>
> 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.
>>>>>
>>>>>
> Is it possible to scrape some of this info from github, gerrit, etc.?
> Perhaps portions of this could be automated to help with maintenance and to
> keep the information up-to-date.
>

[-- Attachment #2: Type: text/html, Size: 1454 bytes --]

Re: Repository Growth

[Patrick Venture]

On Wed, Sep 19, 2018 at 3:03 PM Nancy Yuen <yuenn@google.com> wrote:
>
> +1, I like the idea of having some form of automation to help with the maintenance of this information.
>
> ----------
> Nancy
>
> On Wed, Sep 19, 2018 at 11:45 AM, Bills, Jason M <jason.m.bills@linux.intel.com> wrote:
>>
>>
>>>>>> 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.
>>>>>>
>>
>> Is it possible to scrape some of this info from github, gerrit, etc.? Perhaps portions of this could be automated to help with maintenance and to keep the information up-to-date.

I think this could be scraped if the READMEs were formatted in a
machine-readable way consistently.

>
>

Re: Repository Growth

[Patrick Venture]

On Wed, Sep 19, 2018 at 9:03 AM Adriana Kobylak <anoo@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?
> >
> > Patrick
>

Re: Repository Growth

[Adriana Kobylak]

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?

> Thoughts?
> 
> Patrick

Repository Growth

[Patrick Venture]

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.

Thoughts?

Patrick