> Op 6 feb 2026, om 15:21 heeft Richard Purdie
> <[email protected]> het volgende geschreven:
>
> On Fri, 2026-02-06 at 08:52 +0100, Koen Kooi via lists.openembedded.org wrote:
>>> Op 5 feb 2026, om 16:12 heeft Ross Burton <[email protected]> het
>>> volgende geschreven:
>>> For example:
>>>
>>> - Full automated build testing before patches are merged, to ensure that
>>> nothing breaks
>>> - Support for multiple architectures, so that BSP vendors can use the
>>> recipes and extend them easily as needed
>>> - Every recipe has an active maintainer
>>> - Removal of obsolete recipes from master
>>>
>>> This would mean we can consolidate common recipes, without the risk of
>>> turning into a collection of obsolete unmaintained software that BSP
>>> vendors forked from the year before.
>>>
>>> Does this sound like a direction that would be acceptable?
>>
>> I already had this written down:
>>
>> "Vendor specific changes need careful consideration, backports should
>> be fine, but changes under upstream review or unsubmitted changes
>> should live in their vendor layer as bbappends."
>
> It that instead of, or in addition to the things Ross mentioned? I
> think there are a few key things which need to be written down up front
> to make this successful. Vendors specific changes are definitely one of
> them.
It was a reaction to Ross' "Support for multiple architectures, so that BSP
vendors can use the recipes and extend them easily as needed", so not "instead"
but also not really "in addition". For AI/ML runtimes this is a big, big issue,
even for a single vendor! To take TFlite as an example, upstream has
optimizations Qualcomm GPUs + Android, in our current vendor OE layer we
partially remove those and then add optimizations for Mesa+RustiCL. And that's
just the builtin TFlite delegates!
This mess is exactly why I think it's important to have a layer with the common
runtimes where you don't have to unpatch things first.
>
>> As for maintenance, I'd really like to be able to use git{hub,lab}
>> like pull requests to have proper 2 way communication, but I suspect
>> a separate mailinglist with patchwork+b4 would get us most of the way
>> there.
>
> I think that is up to the maintainers as they are the ones who "live"
> it day to day. Keep in mind that git{hub,lab} work well for
> communication with one maintainer or a small number of them, it doesn't
> work well for wider review. That is probably fine here but I want
> people in general to understand that key difference in the wider
> project context!
Agreed! $previousjob was completely gitlab+MR based, so for smaller
projects/repos I have really come to appreciate having a builtin bot to remind
me as well as having a complete record in one place. For bigger, mixed
maintenance projects like OE-core this would be a major shift and that's where
I think it *really* starts mattering which option gets picked. For example,
Github doesn't have a "Start review" button on the PR pages, you are at least
2 clicks away from being able to summon that. Gitlab is better in that regard,
but only if you pay $$$$ per seat for the premium version.
Anyway, like you said, the maintainers get to pick :)
regards,
Koen
-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#2256):
https://lists.openembedded.org/g/openembedded-architecture/message/2256
Mute This Topic: https://lists.openembedded.org/mt/117540395/21656
Group Owner: [email protected]
Unsubscribe: https://lists.openembedded.org/g/openembedded-architecture/unsub
[[email protected]]
-=-=-=-=-=-=-=-=-=-=-=-
