Call for Gardening Tasks

[Andrew Geissler]

> On Apr 9, 2020, at 4:54 PM, Richard Hanley <rhanley at 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