Can we improve the experience of working on OpenBMC?

[Brad Bishop]

Hi Andrew, thanks for poking at this.

On Wed, Jul 27, 2022 at 10:52:04AM +0930, Andrew Jeffery wrote:
>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

+1

>2. Minimise reviews required to get a given feature or fix integrated into the distro build

+1

>3. Make fork maintenance easy

+1

>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

+1

>8. Support inclusive naming

+1

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

🙂 Really? 

>3. Querying design/implementation/bug properties across the project is hard

+1

>4. Coordinating breaking changes is hard

+1

>5. Coordinating tree-wide changes is hard

+1

>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