Call for Gardening Tasks

Call for Gardening Tasks

[Richard Hanley]

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

Hi everyone,

Last week I started a thread on Open BMC Gardening
<https://lists.ozlabs.org/pipermail/openbmc/2020-April/021100.html>, and I
wanted to kick off the process.

The basic idea here is to get a survey of various improvement tasks
throughout OpenBMC.  Some things might be small refactoring or changes that
can be done incrementally (i.e. weeding the garden). Other tasks might be
more research or structural (i.e. excavating the garden).

Just getting these in writing can be helpful for others to gauge what they
should focus on. It also helps leave breadcrumbs for any new developer
interested in the subject.

So here's how I see this working. Anyone who has some ideas can reply to
this thread with a short to medium description.  Try to avoid new features,
and instead look at ways we could improve the status quo. Think about
changes and tools that would make your day to day life better.

From there we can do a write up about what we know about the issue.  This
can function as an early stage design doc that gives a broad overview on
where the dev's head is at right now.

Finally, we can do a quarterly review to keep the garden refreshed.
Obviously, things can change between that time, but having a semi-regular
cadence will hopefully give us a better chance of keeping this up to date.

- Richard

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

Re: Call for Gardening Tasks

[Richard Hanley]

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

Here are some ideas I have as a wishlist for gardening/improvements.

*Client Models for DBus*
Right now sdbusplus does a pretty good job of making server development
easy.  However, I wish we had some more tooling on the client side. I see a
decent amount of repeated code around ObjectMapper.

One way to separate concerns and cut down on boilerplate is to have a model
library. A call to a model would spin off an async method call to manage
the data marshalling, which would then call a lambda with a fully reified
object.  This is similar in concept to the way models work in web
development.

*Unit Testing in bmcweb*
This is pretty easy to say, and harder to do. I've been thinking a bit
about how to add in unit tests without them being too fragile. (This was
also something that geissonator mentioned).

*DBus Virtualization and Playback*
One thing that I think makes unit testing in some modules hard is that
there is a high barrier around mocking DBus.  I'm not sure the best way to
build this sustainably, but it would help improve our CI testing.

*OpenAPI for Redfish*
So far the general impression I've seen with this is that the Swagger
output for OpenAPI isn't really good for C++.  Either the ergonomics aren't
really good, or there is a lot of code bloat.  I'd love to have some
OpenAPI bindings that work well in OpenBMC.

*RUST!?!?*
I'm betting a lot of people have thought about Rust. I'd love to hear what
people have tried and what are the sticking points.  Any thoughts on what
module/functionality could be a decent candidate for breaking ground here?

-Richard

On Thu, Apr 9, 2020 at 2:54 PM Richard Hanley <rhanley@google.com> wrote:

> Hi everyone,
>
> Last week I started a thread on Open BMC Gardening
> <https://lists.ozlabs.org/pipermail/openbmc/2020-April/021100.html>, and
> I wanted to kick off the process.
>
> The basic idea here is to get a survey of various improvement tasks
> throughout OpenBMC.  Some things might be small refactoring or changes that
> can be done incrementally (i.e. weeding the garden). Other tasks might be
> more research or structural (i.e. excavating the garden).
>
> Just getting these in writing can be helpful for others to gauge what they
> should focus on. It also helps leave breadcrumbs for any new developer
> interested in the subject.
>
> So here's how I see this working. Anyone who has some ideas can reply to
> this thread with a short to medium description.  Try to avoid new features,
> and instead look at ways we could improve the status quo. Think about
> changes and tools that would make your day to day life better.
>
> From there we can do a write up about what we know about the issue.  This
> can function as an early stage design doc that gives a broad overview on
> where the dev's head is at right now.
>
> Finally, we can do a quarterly review to keep the garden refreshed.
> Obviously, things can change between that time, but having a semi-regular
> cadence will hopefully give us a better chance of keeping this up to date.
>
> - Richard
>

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

Re: Call for Gardening Tasks

[Vijay Khemka]

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

I can see following small tasks which need refactoring

IPMID:
Some of standard commands are incomplete here like “restore power policies”, some of sensors  sdrs etc.

Dbus interface:
Define more dbus interfaces being used in common code. I see multiple repos has these interfaces hard coded. And I agree for client side code would really be helpful.

Phosphor package clean up:
There are many phosphor packages in image which are added by default and lots of systemd unit are running irrespective of platform requirements.

Documentation:
Many repos doesn’t have proper documentations and it will be really good to add and a root level documents giving an idea about different features and mapped to multiple available repos.

I will add more once I remember back.

Regards
-Vijay

From: openbmc <openbmc-bounces+vijaykhemka=fb.com@lists.ozlabs.org> on behalf of Richard Hanley <rhanley@google.com>
Date: Thursday, April 9, 2020 at 2:57 PM
To: OpenBMC Maillist <openbmc@lists.ozlabs.org>
Subject: Re: Call for Gardening Tasks

Here are some ideas I have as a wishlist for gardening/improvements.

Client Models for DBus
Right now sdbusplus does a pretty good job of making server development easy.  However, I wish we had some more tooling on the client side. I see a decent amount of repeated code around ObjectMapper.

One way to separate concerns and cut down on boilerplate is to have a model library. A call to a model would spin off an async method call to manage the data marshalling, which would then call a lambda with a fully reified object.  This is similar in concept to the way models work in web development.

Unit Testing in bmcweb
This is pretty easy to say, and harder to do. I've been thinking a bit about how to add in unit tests without them being too fragile. (This was also something that geissonator mentioned).

DBus Virtualization and Playback
One thing that I think makes unit testing in some modules hard is that there is a high barrier around mocking DBus.  I'm not sure the best way to build this sustainably, but it would help improve our CI testing.

OpenAPI for Redfish
So far the general impression I've seen with this is that the Swagger output for OpenAPI isn't really good for C++.  Either the ergonomics aren't really good, or there is a lot of code bloat.  I'd love to have some OpenAPI bindings that work well in OpenBMC.

RUST!?!?
I'm betting a lot of people have thought about Rust. I'd love to hear what people have tried and what are the sticking points.  Any thoughts on what module/functionality could be a decent candidate for breaking ground here?

-Richard

On Thu, Apr 9, 2020 at 2:54 PM Richard Hanley <rhanley@google.com<mailto:rhanley@google.com>> wrote:
Hi everyone,

Last week I started a thread on Open BMC Gardening<https://urldefense.proofpoint.com/v2/url?u=https-3A__lists.ozlabs.org_pipermail_openbmc_2020-2DApril_021100.html&d=DwMFaQ&c=5VD0RTtNlTh3ycd41b3MUw&r=v9MU0Ki9pWnTXCWwjHPVgpnCR80vXkkcrIaqU7USl5g&m=fAZZtmWl4g8Vngk56_Rs09hgS96TYQMeyRsyZKGHzAo&s=HXdHl56jq4p5eXbhyUHUkkmoF_hGh5tJWMUaVKQ68VM&e=>, and I wanted to kick off the process.

The basic idea here is to get a survey of various improvement tasks throughout OpenBMC.  Some things might be small refactoring or changes that can be done incrementally (i.e. weeding the garden). Other tasks might be more research or structural (i.e. excavating the garden).

Just getting these in writing can be helpful for others to gauge what they should focus on. It also helps leave breadcrumbs for any new developer interested in the subject.

So here's how I see this working. Anyone who has some ideas can reply to this thread with a short to medium description.  Try to avoid new features, and instead look at ways we could improve the status quo. Think about changes and tools that would make your day to day life better.

From there we can do a write up about what we know about the issue.  This can function as an early stage design doc that gives a broad overview on where the dev's head is at right now.

Finally, we can do a quarterly review to keep the garden refreshed. Obviously, things can change between that time, but having a semi-regular cadence will hopefully give us a better chance of keeping this up to date.

- Richard

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

Re: Call for Gardening Tasks

[Joseph Reynolds]

On 4/9/20 5:19 PM, Vijay Khemka wrote:
>
> I can see following small tasks which need refactoring
>
> IPMID:
>
> Some of standard commands are incomplete here like “restore power 
> policies”, some of sensors  sdrs etc.
>
> Dbus interface:
>
> Define more dbus interfaces being used in common code. I see multiple 
> repos has these interfaces hard coded. And I agree for client side 
> code would really be helpful.
>
> Phosphor package clean up:
>
> There are many phosphor packages in image which are added by default 
> and lots of systemd unit are running irrespective of platform 
> requirements.
>
> Documentation:
>
> Many repos doesn’t have proper documentations and it will be really 
> good to add and a root level documents giving an idea about different 
> features and mapped to multiple available repos.
>

Can we flesh out the list of features?
https://github.com/openbmc/docs/blob/master/features.md


The openbmc/docs repo has good stuff for developers.  Can we take it the 
next level by adding:
- Guide for system integrators - source and build config, signing keys, etc.
- Guide for initial BMC setup - genesis boot, discovery, configure IP, 
certs, users, etc.
- Guide for system admins - ongoing tasks like auditing logs, firmware 
updates, etc.
- Security technical implementation guide (STIG).

We've discussed these in the OpenBMC security working group, and I've 
collected some details here:
https://github.com/ibm-openbmc/dev/issues/1531

I would be happy to contribute to these ... just looking for someone to 
collaborate with.  :-)

> I will add more once I remember back.
>
> Regards
>
> -Vijay
>
> *From: *openbmc <openbmc-bounces+vijaykhemka=fb.com@lists.ozlabs.org> 
> on behalf of Richard Hanley <rhanley@google.com>
> *Date: *Thursday, April 9, 2020 at 2:57 PM
> *To: *OpenBMC Maillist <openbmc@lists.ozlabs.org>
> *Subject: *Re: Call for Gardening Tasks
>
> Here are some ideas I have as a wishlist for gardening/improvements.
>
> *Client Models for DBus*
>
> Right now sdbusplus does a pretty good job of making server 
> development easy.  However, I wish we had some more tooling on the 
> client side. I see a decent amount of repeated code around ObjectMapper.
>
> One way to separate concerns and cut down on boilerplate is to have a 
> model library. A call to a model would spin off an async method call 
> to manage the data marshalling, which would then call a lambda with a 
> fully reified object.  This is similar in concept to the way models 
> work in web development.
>
> *Unit Testing in bmcweb*
>
> This is pretty easy to say, and harder to do. I've been thinking a bit 
> about how to add in unit tests without them being too fragile. (This 
> was also something that geissonator mentioned).
>
> *DBus Virtualization and Playback*
>
> One thing that I think makes unit testing in some modules hard is that 
> there is a high barrier around mocking DBus.  I'm not sure the best 
> way to build this sustainably, but it would help improve our CI testing.
>
> *OpenAPI for Redfish*
>
> So far the general impression I've seen with this is that the Swagger 
> output for OpenAPI isn't really good for C++.  Either the ergonomics 
> aren't really good, or there is a lot of code bloat.  I'd love to have 
> some OpenAPI bindings that work well in OpenBMC.
>
> *RUST!?!?*
>
> I'm betting a lot of people have thought about Rust. I'd love to hear 
> what people have tried and what are the sticking points.  Any thoughts 
> on what module/functionality could be a decent candidate for breaking 
> ground here?
>

We discussed the rust language in the OpenBMC security working group 
meetings 2019-10-02
OpenBMC security working group minutes:
https://docs.google.com/document/d/1b7x9BaxsfcukQDqbvZsU2ehMq4xoJRQvLxxsDUWmAOI

> -Richard
>
> On Thu, Apr 9, 2020 at 2:54 PM Richard Hanley <rhanley@google.com 
> <mailto:rhanley@google.com>> wrote:
>
>     Hi everyone,
>
>     Last week I started a thread on Open BMC Gardening
>     <https://urldefense.proofpoint.com/v2/url?u=https-3A__lists.ozlabs.org_pipermail_openbmc_2020-2DApril_021100.html&d=DwMFaQ&c=5VD0RTtNlTh3ycd41b3MUw&r=v9MU0Ki9pWnTXCWwjHPVgpnCR80vXkkcrIaqU7USl5g&m=fAZZtmWl4g8Vngk56_Rs09hgS96TYQMeyRsyZKGHzAo&s=HXdHl56jq4p5eXbhyUHUkkmoF_hGh5tJWMUaVKQ68VM&e=>,
>     and I wanted to kick off the process.
>
>     The basic idea here is to get a survey of various
>     improvement tasks throughout OpenBMC.  Some things might be small
>     refactoring or changes that can be done incrementally (i.e.
>     weeding the garden). Other tasks might be more research or
>     structural (i.e. excavating the garden).
>
>     Just getting these in writing can be helpful for others to gauge
>     what they should focus on. It also helps leave breadcrumbs for any
>     new developer interested in the subject.
>

Richard,

Thanks for your efforts to move this forward.

Security wish list here: 
https://github.com/openbmc/openbmc/wiki/Security-working-group#security-feature-wish-list

- Joseph

>     So here's how I see this working. Anyone who has some ideas can
>     reply to this thread with a short to medium description.  Try to
>     avoid new features, and instead look at ways we could improve the
>     status quo. Think about changes and tools that would make your day
>     to day life better.
>
>     From there we can do a write up about what we know about the
>     issue.  This can function as an early stage design doc that gives
>     a broad overview on where the dev's head is at right now.
>
>     Finally, we can do a quarterly review to keep the garden
>     refreshed. Obviously, things can change between that time, but
>     having a semi-regular cadence will hopefully give us a better
>     chance of keeping this up to date.
>
>     - Richard
>

Re: Call for Gardening Tasks

[krtaylor]

On 4/10/20 9:23 AM, Joseph Reynolds wrote:
> On 4/9/20 5:19 PM, Vijay Khemka wrote:
>>
>> I can see following small tasks which need refactoring
>>
>> IPMID:
>>
>> Some of standard commands are incomplete here like “restore power 
>> policies”, some of sensors  sdrs etc.
>>
>> Dbus interface:
>>
>> Define more dbus interfaces being used in common code. I see multiple 
>> repos has these interfaces hard coded. And I agree for client side 
>> code would really be helpful.
>>
>> Phosphor package clean up:
>>
>> There are many phosphor packages in image which are added by default 
>> and lots of systemd unit are running irrespective of platform 
>> requirements.
>>
>> Documentation:
>>
>> Many repos doesn’t have proper documentations and it will be really 
>> good to add and a root level documents giving an idea about different 
>> features and mapped to multiple available repos.
>>
> 
> Can we flesh out the list of features?
> https://github.com/openbmc/docs/blob/master/features.md

Heck, can we start by simply fleshing out what devs (companies) are/have 
worked on for this release?  ;-)
https://github.com/openbmc/openbmc/wiki/Current-Release-Content

- krtaylor

> 
> The openbmc/docs repo has good stuff for developers.  Can we take it the 
> next level by adding:
> - Guide for system integrators - source and build config, signing keys, 
> etc.
> - Guide for initial BMC setup - genesis boot, discovery, configure IP, 
> certs, users, etc.
> - Guide for system admins - ongoing tasks like auditing logs, firmware 
> updates, etc.
> - Security technical implementation guide (STIG).
> 
> We've discussed these in the OpenBMC security working group, and I've 
> collected some details here:
> https://github.com/ibm-openbmc/dev/issues/1531
> 
> I would be happy to contribute to these ... just looking for someone to 
> collaborate with.  :-)
> 
>> I will add more once I remember back.
>>
>> Regards
>>
>> -Vijay
>>
>> *From: *openbmc <openbmc-bounces+vijaykhemka=fb.com@lists.ozlabs.org> 
>> on behalf of Richard Hanley <rhanley@google.com>
>> *Date: *Thursday, April 9, 2020 at 2:57 PM
>> *To: *OpenBMC Maillist <openbmc@lists.ozlabs.org>
>> *Subject: *Re: Call for Gardening Tasks
>>
>> Here are some ideas I have as a wishlist for gardening/improvements.
>>
>> *Client Models for DBus*
>>
>> Right now sdbusplus does a pretty good job of making server 
>> development easy.  However, I wish we had some more tooling on the 
>> client side. I see a decent amount of repeated code around ObjectMapper.
>>
>> One way to separate concerns and cut down on boilerplate is to have a 
>> model library. A call to a model would spin off an async method call 
>> to manage the data marshalling, which would then call a lambda with a 
>> fully reified object.  This is similar in concept to the way models 
>> work in web development.
>>
>> *Unit Testing in bmcweb*
>>
>> This is pretty easy to say, and harder to do. I've been thinking a bit 
>> about how to add in unit tests without them being too fragile. (This 
>> was also something that geissonator mentioned).
>>
>> *DBus Virtualization and Playback*
>>
>> One thing that I think makes unit testing in some modules hard is that 
>> there is a high barrier around mocking DBus.  I'm not sure the best 
>> way to build this sustainably, but it would help improve our CI testing.
>>
>> *OpenAPI for Redfish*
>>
>> So far the general impression I've seen with this is that the Swagger 
>> output for OpenAPI isn't really good for C++.  Either the ergonomics 
>> aren't really good, or there is a lot of code bloat.  I'd love to have 
>> some OpenAPI bindings that work well in OpenBMC.
>>
>> *RUST!?!?*
>>
>> I'm betting a lot of people have thought about Rust. I'd love to hear 
>> what people have tried and what are the sticking points.  Any thoughts 
>> on what module/functionality could be a decent candidate for breaking 
>> ground here?
>>
> 
> We discussed the rust language in the OpenBMC security working group 
> meetings 2019-10-02
> OpenBMC security working group minutes:
> https://docs.google.com/document/d/1b7x9BaxsfcukQDqbvZsU2ehMq4xoJRQvLxxsDUWmAOI 
> 
> 
>> -Richard
>>
>> On Thu, Apr 9, 2020 at 2:54 PM Richard Hanley <rhanley@google.com 
>> <mailto:rhanley@google.com>> wrote:
>>
>>     Hi everyone,
>>
>>     Last week I started a thread on Open BMC Gardening
>>     
>> <https://urldefense.proofpoint.com/v2/url?u=https-3A__lists.ozlabs.org_pipermail_openbmc_2020-2DApril_021100.html&d=DwMFaQ&c=5VD0RTtNlTh3ycd41b3MUw&r=v9MU0Ki9pWnTXCWwjHPVgpnCR80vXkkcrIaqU7USl5g&m=fAZZtmWl4g8Vngk56_Rs09hgS96TYQMeyRsyZKGHzAo&s=HXdHl56jq4p5eXbhyUHUkkmoF_hGh5tJWMUaVKQ68VM&e=>, 
>>
>>     and I wanted to kick off the process.
>>
>>     The basic idea here is to get a survey of various
>>     improvement tasks throughout OpenBMC.  Some things might be small
>>     refactoring or changes that can be done incrementally (i.e.
>>     weeding the garden). Other tasks might be more research or
>>     structural (i.e. excavating the garden).
>>
>>     Just getting these in writing can be helpful for others to gauge
>>     what they should focus on. It also helps leave breadcrumbs for any
>>     new developer interested in the subject.
>>
> 
> Richard,
> 
> Thanks for your efforts to move this forward.
> 
> Security wish list here: 
> https://github.com/openbmc/openbmc/wiki/Security-working-group#security-feature-wish-list 
> 
> 
> - Joseph
> 
>>     So here's how I see this working. Anyone who has some ideas can
>>     reply to this thread with a short to medium description.  Try to
>>     avoid new features, and instead look at ways we could improve the
>>     status quo. Think about changes and tools that would make your day
>>     to day life better.
>>
>>     From there we can do a write up about what we know about the
>>     issue.  This can function as an early stage design doc that gives
>>     a broad overview on where the dev's head is at right now.
>>
>>     Finally, we can do a quarterly review to keep the garden
>>     refreshed. Obviously, things can change between that time, but
>>     having a semi-regular cadence will hopefully give us a better
>>     chance of keeping this up to date.
>>
>>     - Richard
>>
> 

Re: Call for Gardening Tasks

[James Feist]

On 4/10/2020 7:30 AM, krtaylor wrote:
> On 4/10/20 9:23 AM, Joseph Reynolds wrote:
>> On 4/9/20 5:19 PM, Vijay Khemka wrote:

I'd really like to see clang-tidy or other checks for style added into 
the build CI. The number of style violations waste lots of time in 
code-review for both the submitter and reviewers.

>>>
>>> I can see following small tasks which need refactoring
>>>
>>> IPMID:
>>>
>>> Some of standard commands are incomplete here like “restore power 
>>> policies”, some of sensors  sdrs etc.
>>>
>>> Dbus interface:
>>>
>>> Define more dbus interfaces being used in common code. I see multiple 
>>> repos has these interfaces hard coded. And I agree for client side 
>>> code would really be helpful.
>>>
>>> Phosphor package clean up:
>>>
>>> There are many phosphor packages in image which are added by default 
>>> and lots of systemd unit are running irrespective of platform 
>>> requirements.
>>>
>>> Documentation:
>>>
>>> Many repos doesn’t have proper documentations and it will be really 
>>> good to add and a root level documents giving an idea about different 
>>> features and mapped to multiple available repos.
>>>
>>
>> Can we flesh out the list of features?
>> https://github.com/openbmc/docs/blob/master/features.md
> 
> Heck, can we start by simply fleshing out what devs (companies) are/have 
> worked on for this release?  ;-)
> https://github.com/openbmc/openbmc/wiki/Current-Release-Content
> 
> - krtaylor
> 
>>
>> The openbmc/docs repo has good stuff for developers.  Can we take it 
>> the next level by adding:
>> - Guide for system integrators - source and build config, signing 
>> keys, etc.
>> - Guide for initial BMC setup - genesis boot, discovery, configure IP, 
>> certs, users, etc.
>> - Guide for system admins - ongoing tasks like auditing logs, firmware 
>> updates, etc.
>> - Security technical implementation guide (STIG).
>>
>> We've discussed these in the OpenBMC security working group, and I've 
>> collected some details here:
>> https://github.com/ibm-openbmc/dev/issues/1531
>>
>> I would be happy to contribute to these ... just looking for someone 
>> to collaborate with.  :-)
>>
>>> I will add more once I remember back.
>>>
>>> Regards
>>>
>>> -Vijay
>>>
>>> *From: *openbmc <openbmc-bounces+vijaykhemka=fb.com@lists.ozlabs.org> 
>>> on behalf of Richard Hanley <rhanley@google.com>
>>> *Date: *Thursday, April 9, 2020 at 2:57 PM
>>> *To: *OpenBMC Maillist <openbmc@lists.ozlabs.org>
>>> *Subject: *Re: Call for Gardening Tasks
>>>
>>> Here are some ideas I have as a wishlist for gardening/improvements.
>>>
>>> *Client Models for DBus*
>>>
>>> Right now sdbusplus does a pretty good job of making server 
>>> development easy.  However, I wish we had some more tooling on the 
>>> client side. I see a decent amount of repeated code around ObjectMapper.
>>>
>>> One way to separate concerns and cut down on boilerplate is to have a 
>>> model library. A call to a model would spin off an async method call 
>>> to manage the data marshalling, which would then call a lambda with a 
>>> fully reified object.  This is similar in concept to the way models 
>>> work in web development.
>>>
>>> *Unit Testing in bmcweb*
>>>
>>> This is pretty easy to say, and harder to do. I've been thinking a 
>>> bit about how to add in unit tests without them being too fragile. 
>>> (This was also something that geissonator mentioned).
>>>
>>> *DBus Virtualization and Playback*
>>>
>>> One thing that I think makes unit testing in some modules hard is 
>>> that there is a high barrier around mocking DBus.  I'm not sure the 
>>> best way to build this sustainably, but it would help improve our CI 
>>> testing.
>>>
>>> *OpenAPI for Redfish*
>>>
>>> So far the general impression I've seen with this is that the Swagger 
>>> output for OpenAPI isn't really good for C++.  Either the ergonomics 
>>> aren't really good, or there is a lot of code bloat.  I'd love to 
>>> have some OpenAPI bindings that work well in OpenBMC.
>>>
>>> *RUST!?!?*
>>>
>>> I'm betting a lot of people have thought about Rust. I'd love to hear 
>>> what people have tried and what are the sticking points.  Any 
>>> thoughts on what module/functionality could be a decent candidate for 
>>> breaking ground here?
>>>
>>
>> We discussed the rust language in the OpenBMC security working group 
>> meetings 2019-10-02
>> OpenBMC security working group minutes:
>> https://docs.google.com/document/d/1b7x9BaxsfcukQDqbvZsU2ehMq4xoJRQvLxxsDUWmAOI 
>>
>>
>>> -Richard
>>>
>>> On Thu, Apr 9, 2020 at 2:54 PM Richard Hanley <rhanley@google.com 
>>> <mailto:rhanley@google.com>> wrote:
>>>
>>>     Hi everyone,
>>>
>>>     Last week I started a thread on Open BMC Gardening
>>> <https://urldefense.proofpoint.com/v2/url?u=https-3A__lists.ozlabs.org_pipermail_openbmc_2020-2DApril_021100.html&d=DwMFaQ&c=5VD0RTtNlTh3ycd41b3MUw&r=v9MU0Ki9pWnTXCWwjHPVgpnCR80vXkkcrIaqU7USl5g&m=fAZZtmWl4g8Vngk56_Rs09hgS96TYQMeyRsyZKGHzAo&s=HXdHl56jq4p5eXbhyUHUkkmoF_hGh5tJWMUaVKQ68VM&e=>, 
>>>
>>>     and I wanted to kick off the process.
>>>
>>>     The basic idea here is to get a survey of various
>>>     improvement tasks throughout OpenBMC.  Some things might be small
>>>     refactoring or changes that can be done incrementally (i.e.
>>>     weeding the garden). Other tasks might be more research or
>>>     structural (i.e. excavating the garden).
>>>
>>>     Just getting these in writing can be helpful for others to gauge
>>>     what they should focus on. It also helps leave breadcrumbs for any
>>>     new developer interested in the subject.
>>>
>>
>> Richard,
>>
>> Thanks for your efforts to move this forward.
>>
>> Security wish list here: 
>> https://github.com/openbmc/openbmc/wiki/Security-working-group#security-feature-wish-list 
>>
>>
>> - Joseph
>>
>>>     So here's how I see this working. Anyone who has some ideas can
>>>     reply to this thread with a short to medium description.  Try to
>>>     avoid new features, and instead look at ways we could improve the
>>>     status quo. Think about changes and tools that would make your day
>>>     to day life better.
>>>
>>>     From there we can do a write up about what we know about the
>>>     issue.  This can function as an early stage design doc that gives
>>>     a broad overview on where the dev's head is at right now.
>>>
>>>     Finally, we can do a quarterly review to keep the garden
>>>     refreshed. Obviously, things can change between that time, but
>>>     having a semi-regular cadence will hopefully give us a better
>>>     chance of keeping this up to date.
>>>
>>>     - Richard
>>>
>>
> 

RE: [EXTERNAL] Re: Call for Gardening Tasks

[Neeraj Ladkani]

My wish list 

- Documentation is a biggest gap in adoption so we should try to have clear documentation on 
	- Build
	- Dev Practices 
	- Debug 
	- Best Known Methods of debugging ( Static and Runtime) 
	- Documentation of each feature 
	- User Guide
- Boot time optimization and runtime optimization ( dbus latencies) 
- OpenBMC resiliency (bmc hang, bmc corruption etc ) 
- Package Manager- Ability to update only required services 
- BMC update tool that runs from Windows

Thanks
Neeraj


-----Original Message-----
From: openbmc <openbmc-bounces+neladk=microsoft.com@lists.ozlabs.org> On Behalf Of krtaylor
Sent: Friday, April 10, 2020 7:31 AM
To: openbmc@lists.ozlabs.org
Subject: [EXTERNAL] Re: Call for Gardening Tasks

On 4/10/20 9:23 AM, Joseph Reynolds wrote:
> On 4/9/20 5:19 PM, Vijay Khemka wrote:
>>
>> I can see following small tasks which need refactoring
>>
>> IPMID:
>>
>> Some of standard commands are incomplete here like “restore power 
>> policies”, some of sensors  sdrs etc.
>>
>> Dbus interface:
>>
>> Define more dbus interfaces being used in common code. I see multiple 
>> repos has these interfaces hard coded. And I agree for client side 
>> code would really be helpful.
>>
>> Phosphor package clean up:
>>
>> There are many phosphor packages in image which are added by default 
>> and lots of systemd unit are running irrespective of platform 
>> requirements.
>>
>> Documentation:
>>
>> Many repos doesn’t have proper documentations and it will be really 
>> good to add and a root level documents giving an idea about different 
>> features and mapped to multiple available repos.
>>
> 
> Can we flesh out the list of features?
> https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgith
> ub.com%2Fopenbmc%2Fdocs%2Fblob%2Fmaster%2Ffeatures.md&amp;data=02%7C01
> %7Cneladk%40microsoft.com%7C916cecb7f02d49a69bb608d7dd5bfa4f%7C72f988b
> f86f141af91ab2d7cd011db47%7C1%7C0%7C637221259424623201&amp;sdata=26yPC
> Yk5SPlxyj6WrHtlpchoB0mzq9AlFgb6j18Z4iA%3D&amp;reserved=0

Heck, can we start by simply fleshing out what devs (companies) are/have worked on for this release?  ;-)
https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fopenbmc%2Fopenbmc%2Fwiki%2FCurrent-Release-Content&amp;data=02%7C01%7Cneladk%40microsoft.com%7C916cecb7f02d49a69bb608d7dd5bfa4f%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637221259424623201&amp;sdata=2zoKeeNq3EX5qXfUhVhsf1RqHNaO399ujhERcBznENg%3D&amp;reserved=0

- krtaylor

> 
> The openbmc/docs repo has good stuff for developers.  Can we take it 
> the next level by adding:
> - Guide for system integrators - source and build config, signing 
> keys, etc.
> - Guide for initial BMC setup - genesis boot, discovery, configure IP, 
> certs, users, etc.
> - Guide for system admins - ongoing tasks like auditing logs, firmware 
> updates, etc.
> - Security technical implementation guide (STIG).
> 
> We've discussed these in the OpenBMC security working group, and I've 
> collected some details here:
> https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgith
> ub.com%2Fibm-openbmc%2Fdev%2Fissues%2F1531&amp;data=02%7C01%7Cneladk%4
> 0microsoft.com%7C916cecb7f02d49a69bb608d7dd5bfa4f%7C72f988bf86f141af91
> ab2d7cd011db47%7C1%7C0%7C637221259424623201&amp;sdata=ke66m%2FP7mUydIN
> 3ZIkEeyqa%2FROX8fwaalodOQIkIXbM%3D&amp;reserved=0
> 
> I would be happy to contribute to these ... just looking for someone 
> to collaborate with.  :-)
> 
>> I will add more once I remember back.
>>
>> Regards
>>
>> -Vijay
>>
>> *From: *openbmc <openbmc-bounces+vijaykhemka=fb.com@lists.ozlabs.org>
>> on behalf of Richard Hanley <rhanley@google.com>
>> *Date: *Thursday, April 9, 2020 at 2:57 PM
>> *To: *OpenBMC Maillist <openbmc@lists.ozlabs.org>
>> *Subject: *Re: Call for Gardening Tasks
>>
>> Here are some ideas I have as a wishlist for gardening/improvements.
>>
>> *Client Models for DBus*
>>
>> Right now sdbusplus does a pretty good job of making server 
>> development easy.  However, I wish we had some more tooling on the 
>> client side. I see a decent amount of repeated code around ObjectMapper.
>>
>> One way to separate concerns and cut down on boilerplate is to have a 
>> model library. A call to a model would spin off an async method call 
>> to manage the data marshalling, which would then call a lambda with a 
>> fully reified object.  This is similar in concept to the way models 
>> work in web development.
>>
>> *Unit Testing in bmcweb*
>>
>> This is pretty easy to say, and harder to do. I've been thinking a 
>> bit about how to add in unit tests without them being too fragile. 
>> (This was also something that geissonator mentioned).
>>
>> *DBus Virtualization and Playback*
>>
>> One thing that I think makes unit testing in some modules hard is 
>> that there is a high barrier around mocking DBus.  I'm not sure the 
>> best way to build this sustainably, but it would help improve our CI testing.
>>
>> *OpenAPI for Redfish*
>>
>> So far the general impression I've seen with this is that the Swagger 
>> output for OpenAPI isn't really good for C++.  Either the ergonomics 
>> aren't really good, or there is a lot of code bloat.  I'd love to 
>> have some OpenAPI bindings that work well in OpenBMC.
>>
>> *RUST!?!?*
>>
>> I'm betting a lot of people have thought about Rust. I'd love to hear 
>> what people have tried and what are the sticking points.  Any 
>> thoughts on what module/functionality could be a decent candidate for 
>> breaking ground here?
>>
> 
> We discussed the rust language in the OpenBMC security working group 
> meetings 2019-10-02 OpenBMC security working group minutes:
> https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fdocs
> .google.com%2Fdocument%2Fd%2F1b7x9BaxsfcukQDqbvZsU2ehMq4xoJRQvLxxsDUWm
> AOI&amp;data=02%7C01%7Cneladk%40microsoft.com%7C916cecb7f02d49a69bb608
> d7dd5bfa4f%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C63722125942462
> 3201&amp;sdata=ilCVzuzeyRqDFu56ha9zXoE1%2F6mpGNK0e7YwQIuoRSg%3D&amp;re
> served=0
> 
> 
>> -Richard
>>
>> On Thu, Apr 9, 2020 at 2:54 PM Richard Hanley <rhanley@google.com 
>> <mailto:rhanley@google.com>> wrote:
>>
>>     Hi everyone,
>>
>>     Last week I started a thread on Open BMC Gardening
>>     
>> <https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fur
>> ldefense.proofpoint.com%2Fv2%2Furl%3Fu%3Dhttps-3A__lists.ozlabs.org_p
>> ipermail_openbmc_2020-2DApril_021100.html%26d%3DDwMFaQ%26c%3D5VD0RTtN
>> lTh3ycd41b3MUw%26r%3Dv9MU0Ki9pWnTXCWwjHPVgpnCR80vXkkcrIaqU7USl5g%26m%
>> 3DfAZZtmWl4g8Vngk56_Rs09hgS96TYQMeyRsyZKGHzAo%26s%3DHXdHl56jq4p5eXbhy
>> UHUkkmoF_hGh5tJWMUaVKQ68VM%26e%3D&amp;data=02%7C01%7Cneladk%40microso
>> ft.com%7C916cecb7f02d49a69bb608d7dd5bfa4f%7C72f988bf86f141af91ab2d7cd
>> 011db47%7C1%7C0%7C637221259424623201&amp;sdata=supFlb87zz%2FJCHbTfRkZ
>> iDs4qI63%2BitxltEnVh6RQ0s%3D&amp;reserved=0>,
>>
>>     and I wanted to kick off the process.
>>
>>     The basic idea here is to get a survey of various
>>     improvement tasks throughout OpenBMC.  Some things might be small
>>     refactoring or changes that can be done incrementally (i.e.
>>     weeding the garden). Other tasks might be more research or
>>     structural (i.e. excavating the garden).
>>
>>     Just getting these in writing can be helpful for others to gauge
>>     what they should focus on. It also helps leave breadcrumbs for 
>> any
>>     new developer interested in the subject.
>>
> 
> Richard,
> 
> Thanks for your efforts to move this forward.
> 
> Security wish list here: 
> https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgith
> ub.com%2Fopenbmc%2Fopenbmc%2Fwiki%2FSecurity-working-group%23security-
> feature-wish-list&amp;data=02%7C01%7Cneladk%40microsoft.com%7C916cecb7
> f02d49a69bb608d7dd5bfa4f%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C
> 637221259424623201&amp;sdata=BnjKuY%2FHdSY9HfZhVSenKiK9L4SZ%2FD8sNiler
> wD23dU%3D&amp;reserved=0
> 
> 
> - Joseph
> 
>>     So here's how I see this working. Anyone who has some ideas can
>>     reply to this thread with a short to medium description.  Try to
>>     avoid new features, and instead look at ways we could improve the
>>     status quo. Think about changes and tools that would make your 
>> day
>>     to day life better.
>>
>>     From there we can do a write up about what we know about the
>>     issue.  This can function as an early stage design doc that gives
>>     a broad overview on where the dev's head is at right now.
>>
>>     Finally, we can do a quarterly review to keep the garden
>>     refreshed. Obviously, things can change between that time, but
>>     having a semi-regular cadence will hopefully give us a better
>>     chance of keeping this up to date.
>>
>>     - Richard
>>
> 

Re: Call for Gardening Tasks

[Andrew Geissler]

> On Apr 9, 2020, at 4:54 PM, Richard Hanley <rhanley@google.com> wrote:
> 
> Hi everyone,
> 
> Last week I started a thread on Open BMC Gardening, and I wanted to kick off the process.
> 
> The basic idea here is to get a survey of various improvement tasks throughout OpenBMC.  Some things might be small refactoring or changes that can be done incrementally (i.e. weeding the garden). Other tasks might be more research or structural (i.e. excavating the garden).
> 
> Just getting these in writing can be helpful for others to gauge what they should focus on. It also helps leave breadcrumbs for any new developer interested in the subject.
> 
> So here's how I see this working. Anyone who has some ideas can reply to this thread with a short to medium description.  Try to avoid new features, and instead look at ways we could improve the status quo. Think about changes and tools that would make your day to day life better.

Meson Migrations
Moving projects over to meson build system. I think(?) we can all agree it’s the best build system for OpenBMC. There’s some good examples out there of other repos doing it. Should be fairly easy for a new person to migrate a repository over and gets them some good experience with the community.

Gerrit Owner Plugin
Gerrit provides the ability to assign maintainers on a sub-directory basis. We just need someone to dig into this a bit. This would provide some added flexibility on co-maintainers on repositories and allow my next item to go forward.

Build Simplification
Go back to everything in openbmc/openbmc and get rid of the meta-* sub-repos. I believe this was mostly done so we could have more fine grained maintainers. It makes things complicated (merge into sub repo, merge bump into meta-*, then run another script to move the meta-* into openbmc/openbmc) and doubles our CI resource requirements.

Systemd Visualization
Another complicated area of OpenBMC is our systemd targets and services. Building on the upstream tools to visualize our systemd targets and services would be useful to new people.

> 
> From there we can do a write up about what we know about the issue.  This can function as an early stage design doc that gives a broad overview on where the dev's head is at right now.
> 
> Finally, we can do a quarterly review to keep the garden refreshed. Obviously, things can change between that time, but having a semi-regular cadence will hopefully give us a better chance of keeping this up to date.
> 
> - Richard

Re: Call for Gardening Tasks

[Patrick Williams]

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

On Fri, Apr 10, 2020 at 11:00:48AM -0700, James Feist wrote:
> On 4/10/2020 7:30 AM, krtaylor wrote:
> > On 4/10/20 9:23 AM, Joseph Reynolds wrote:
> >> On 4/9/20 5:19 PM, Vijay Khemka wrote:
> 
> I'd really like to see clang-tidy or other checks for style added into 
> the build CI. The number of style violations waste lots of time in 
> code-review for both the submitter and reviewers.

Do we have .clang-tidy files in the repositories?  Meson has built-in
support for generating a 'ninja clang-tidy' so it is pretty trivial to
enable.

-- 
Patrick Williams

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 833 bytes --]

Re: Call for Gardening Tasks

[Vijay Khemka]

On 4/10/20, 11:02 AM, "openbmc on behalf of James Feist" <openbmc-bounces+vijaykhemka=fb.com@lists.ozlabs.org on behalf of james.feist@linux.intel.com> wrote:

    On 4/10/2020 7:30 AM, krtaylor wrote:
    > On 4/10/20 9:23 AM, Joseph Reynolds wrote:
    >> On 4/9/20 5:19 PM, Vijay Khemka wrote:
    
    I'd really like to see clang-tidy or other checks for style added into 
    the build CI. The number of style violations waste lots of time in 
    code-review for both the submitter and reviewers.

Yes I agree, we may also need to add some basic automation testing in CI.
    
    >>>
    >>> I can see following small tasks which need refactoring
    >>>
    >>> IPMID:
    >>>
    >>> Some of standard commands are incomplete here like “restore power 
    >>> policies”, some of sensors  sdrs etc.
    >>>
    >>> Dbus interface:
    >>>
    >>> Define more dbus interfaces being used in common code. I see multiple 
    >>> repos has these interfaces hard coded. And I agree for client side 
    >>> code would really be helpful.
    >>>
    >>> Phosphor package clean up:
    >>>
    >>> There are many phosphor packages in image which are added by default 
    >>> and lots of systemd unit are running irrespective of platform 
    >>> requirements.
    >>>
    >>> Documentation:
    >>>
    >>> Many repos doesn’t have proper documentations and it will be really 
    >>> good to add and a root level documents giving an idea about different 
    >>> features and mapped to multiple available repos.
    >>>
    >>
    >> Can we flesh out the list of features?
    >> https://github.com/openbmc/docs/blob/master/features.md
    > 
    > Heck, can we start by simply fleshing out what devs (companies) are/have 
    > worked on for this release?  ;-)
    > https://github.com/openbmc/openbmc/wiki/Current-Release-Content
    > 
    > - krtaylor
    > 
    >>
    >> The openbmc/docs repo has good stuff for developers.  Can we take it 
    >> the next level by adding:
    >> - Guide for system integrators - source and build config, signing 
    >> keys, etc.
    >> - Guide for initial BMC setup - genesis boot, discovery, configure IP, 
    >> certs, users, etc.
    >> - Guide for system admins - ongoing tasks like auditing logs, firmware 
    >> updates, etc.
    >> - Security technical implementation guide (STIG).
    >>
    >> We've discussed these in the OpenBMC security working group, and I've 
    >> collected some details here:
    >> https://github.com/ibm-openbmc/dev/issues/1531
    >>
    >> I would be happy to contribute to these ... just looking for someone 
    >> to collaborate with.  :-)
    >>
    >>> I will add more once I remember back.
    >>>
    >>> Regards
    >>>
    >>> -Vijay
    >>>
    >>> *From: *openbmc <openbmc-bounces+vijaykhemka=fb.com@lists.ozlabs.org> 
    >>> on behalf of Richard Hanley <rhanley@google.com>
    >>> *Date: *Thursday, April 9, 2020 at 2:57 PM
    >>> *To: *OpenBMC Maillist <openbmc@lists.ozlabs.org>
    >>> *Subject: *Re: Call for Gardening Tasks
    >>>
    >>> Here are some ideas I have as a wishlist for gardening/improvements.
    >>>
    >>> *Client Models for DBus*
    >>>
    >>> Right now sdbusplus does a pretty good job of making server 
    >>> development easy.  However, I wish we had some more tooling on the 
    >>> client side. I see a decent amount of repeated code around ObjectMapper.
    >>>
    >>> One way to separate concerns and cut down on boilerplate is to have a 
    >>> model library. A call to a model would spin off an async method call 
    >>> to manage the data marshalling, which would then call a lambda with a 
    >>> fully reified object.  This is similar in concept to the way models 
    >>> work in web development.
    >>>
    >>> *Unit Testing in bmcweb*
    >>>
    >>> This is pretty easy to say, and harder to do. I've been thinking a 
    >>> bit about how to add in unit tests without them being too fragile. 
    >>> (This was also something that geissonator mentioned).
    >>>
    >>> *DBus Virtualization and Playback*
    >>>
    >>> One thing that I think makes unit testing in some modules hard is 
    >>> that there is a high barrier around mocking DBus.  I'm not sure the 
    >>> best way to build this sustainably, but it would help improve our CI 
    >>> testing.
    >>>
    >>> *OpenAPI for Redfish*
    >>>
    >>> So far the general impression I've seen with this is that the Swagger 
    >>> output for OpenAPI isn't really good for C++.  Either the ergonomics 
    >>> aren't really good, or there is a lot of code bloat.  I'd love to 
    >>> have some OpenAPI bindings that work well in OpenBMC.
    >>>
    >>> *RUST!?!?*
    >>>
    >>> I'm betting a lot of people have thought about Rust. I'd love to hear 
    >>> what people have tried and what are the sticking points.  Any 
    >>> thoughts on what module/functionality could be a decent candidate for 
    >>> breaking ground here?
    >>>
    >>
    >> We discussed the rust language in the OpenBMC security working group 
    >> meetings 2019-10-02
    >> OpenBMC security working group minutes:
    >> https://urldefense.proofpoint.com/v2/url?u=https-3A__docs.google.com_document_d_1b7x9BaxsfcukQDqbvZsU2ehMq4xoJRQvLxxsDUWmAOI&d=DwIDaQ&c=5VD0RTtNlTh3ycd41b3MUw&r=v9MU0Ki9pWnTXCWwjHPVgpnCR80vXkkcrIaqU7USl5g&m=MqzeHbAdDCDQPPqxtL2sbM9gBlKXoGdiz5hj06g1We8&s=gWsiuACR8FSiP_Fmoa1yO1h3IoDH42VkUE6pUOZqRTA&e=  
    >>
    >>
    >>> -Richard
    >>>
    >>> On Thu, Apr 9, 2020 at 2:54 PM Richard Hanley <rhanley@google.com 
    >>> <mailto:rhanley@google.com>> wrote:
    >>>
    >>>     Hi everyone,
    >>>
    >>>     Last week I started a thread on Open BMC Gardening
    >>> <https://urldefense.proofpoint.com/v2/url?u=https-3A__lists.ozlabs.org_pipermail_openbmc_2020-2DApril_021100.html&d=DwMFaQ&c=5VD0RTtNlTh3ycd41b3MUw&r=v9MU0Ki9pWnTXCWwjHPVgpnCR80vXkkcrIaqU7USl5g&m=fAZZtmWl4g8Vngk56_Rs09hgS96TYQMeyRsyZKGHzAo&s=HXdHl56jq4p5eXbhyUHUkkmoF_hGh5tJWMUaVKQ68VM&e=>, 
    >>>
    >>>     and I wanted to kick off the process.
    >>>
    >>>     The basic idea here is to get a survey of various
    >>>     improvement tasks throughout OpenBMC.  Some things might be small
    >>>     refactoring or changes that can be done incrementally (i.e.
    >>>     weeding the garden). Other tasks might be more research or
    >>>     structural (i.e. excavating the garden).
    >>>
    >>>     Just getting these in writing can be helpful for others to gauge
    >>>     what they should focus on. It also helps leave breadcrumbs for any
    >>>     new developer interested in the subject.
    >>>
    >>
    >> Richard,
    >>
    >> Thanks for your efforts to move this forward.
    >>
    >> Security wish list here: 
    >> https://github.com/openbmc/openbmc/wiki/Security-working-group#security-feature-wish-list 
    >>
    >>
    >> - Joseph
    >>
    >>>     So here's how I see this working. Anyone who has some ideas can
    >>>     reply to this thread with a short to medium description.  Try to
    >>>     avoid new features, and instead look at ways we could improve the
    >>>     status quo. Think about changes and tools that would make your day
    >>>     to day life better.
    >>>
    >>>     From there we can do a write up about what we know about the
    >>>     issue.  This can function as an early stage design doc that gives
    >>>     a broad overview on where the dev's head is at right now.
    >>>
    >>>     Finally, we can do a quarterly review to keep the garden
    >>>     refreshed. Obviously, things can change between that time, but
    >>>     having a semi-regular cadence will hopefully give us a better
    >>>     chance of keeping this up to date.
    >>>
    >>>     - Richard
    >>>
    >>
    > 
    

Re: Call for Gardening Tasks

[Lei YU]

On Wed, Apr 15, 2020 at 12:57 AM Patrick Williams <patrick@stwcx.xyz> wrote:
>
> On Fri, Apr 10, 2020 at 11:00:48AM -0700, James Feist wrote:
> > On 4/10/2020 7:30 AM, krtaylor wrote:
> > > On 4/10/20 9:23 AM, Joseph Reynolds wrote:
> > >> On 4/9/20 5:19 PM, Vijay Khemka wrote:
> >
> > I'd really like to see clang-tidy or other checks for style added into
> > the build CI. The number of style violations waste lots of time in
> > code-review for both the submitter and reviewers.
>
> Do we have .clang-tidy files in the repositories?  Meson has built-in
> support for generating a 'ninja clang-tidy' so it is pretty trivial to
> enable.

phosphor-state-manager has .clang-tidy in the repo, and the CI will
invoke run-clang-tidy.py to do the task.
However, it's noticed that it's broken with
https://github.com/openbmc/openbmc-build-scripts/commit/9e5b11f5d5069d244a2dd86b120fcc98fea66d2c

Re: Call for Gardening Tasks

[James Feist]

On 4/14/2020 6:58 PM, Lei YU wrote:
> On Wed, Apr 15, 2020 at 12:57 AM Patrick Williams <patrick@stwcx.xyz> wrote:
>>
>> On Fri, Apr 10, 2020 at 11:00:48AM -0700, James Feist wrote:
>>> On 4/10/2020 7:30 AM, krtaylor wrote:
>>>> On 4/10/20 9:23 AM, Joseph Reynolds wrote:
>>>>> On 4/9/20 5:19 PM, Vijay Khemka wrote:
>>>
>>> I'd really like to see clang-tidy or other checks for style added into
>>> the build CI. The number of style violations waste lots of time in
>>> code-review for both the submitter and reviewers.
>>
>> Do we have .clang-tidy files in the repositories?  Meson has built-in
>> support for generating a 'ninja clang-tidy' so it is pretty trivial to
>> enable.
> 

There was one here: 
https://github.com/openbmc/bmcweb/blob/70ee8cbd4f3ec5b3e3c18967de221a9f3a70cd38/.clang-tidy

It wasn't perfect, but did move bmcweb over to nearly upstream style. If 
there is a .clang-tidy file we could all agree to, even if it isn't 
perfect, that would be great.


> phosphor-state-manager has .clang-tidy in the repo, and the CI will
> invoke run-clang-tidy.py to do the task.
> However, it's noticed that it's broken with
> https://github.com/openbmc/openbmc-build-scripts/commit/9e5b11f5d5069d244a2dd86b120fcc98fea66d2c
> 

Seems to be empty? Or is meson injecting dependencies somewhere? 
https://github.com/openbmc/phosphor-state-manager/blob/master/.clang-tidy