Can we improve the experience of working on OpenBMC?

[Andrew Jeffery]

Hello everyone,

A few months back Ed kicked off a thread about changing how we work on OpenBMC
with the aim to improve the development rate and make it easier to on-board
people to the project:

https://lore.kernel.org/openbmc/CAH2-KxAJS_U8=meCxp8ue7n0bmnzeRpyZOPZpy0h1cFEbbz-HA@mail.gmail.com/

I felt that discussion splintered a bit, with a lot of back-and-forth about
details well down in the weeds. I found this hard to follow, and so put in some
work to try synthesise the discussion into desires for improving how we work,
and practical problems with what we do currently.

Below are the lists of these desires and problems. I think it would be good to
treat this as a survey to understand who feels strongly about what.

If you want to express support for a point then add a +1 below it. Feel free to
suggest new items for either list, or to further discuss a particular item
below its entry.

I feel that with information on what people feel strongly about we can
prioritise what we need address and work forwards from there.

For the record, the mind map that I used to generate these lists is here, which
contains further quotes and references to the original discussion thread:

https://github.com/amboar/openbmc-monorepo-discussion

Some of these might be closely related or considered duplicates of other list
items, but based on the discussions referenced above I felt they were distinct
enough to warrant separate entries.

# Desires

1. Easy sharing of a broad set of application and distro changes
2. Minimise reviews required to get a given feature or fix integrated into the distro build
3. Make fork maintenance easy
4. Provide one place to report bugs across the entire project
5. Minimise effort collecting project statistics
6. Make it easy to add new applications
7. Make it easy to refactor across the entire project
8. Support inclusive naming

# Problems

1. Yocto is hard
    1. Managing patch stacks is hard
    2. Yocto-specific tooling is hard
    3. Finding the right recipe file to inspect/modify is hard
    4. Yocto has too much documentation
2. OpenBMC has too much documentation
3. Querying design/implementation/bug properties across the project is hard
4. Coordinating breaking changes is hard
5. Coordinating tree-wide changes is hard
6. Identifying the right repo to file a bug against is hard
7. Transferring bugs between repos is hard
8. Bug reports are duplicated across repos
9. Bug reports are ignored
10. Working out where to submit a patch is hard
11. Getting patches reviewed is hard
12. New repo requests are bottle-necked

Cheers,

Andrew