Can we improve the experience of working on OpenBMC?
bradleyb at fuzziesquirrel.com
Fri Jul 29 10:10:58 AEST 2022
Hi Andrew, thanks for poking at this.
On Wed, Jul 27, 2022 at 10:52:04AM +0930, Andrew Jeffery wrote:
>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:
>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:
>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.
>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
>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
More information about the openbmc