[stdexec] Long-Term Ownership and Maintenance of stdexec Dependency

[stdexec] Long-Term Ownership and Maintenance of stdexec Dependency

[Chinmoy Dey]

[-- Attachment #1: Type: text/plain, Size: 1942 bytes --]

Hi OpenBMC Community,

I would like to start a discussion around the long-term ownership and maintenance model for the stdexec dependency that is currently part of the OpenBMC dependency chain. As I understand it today:

  *
bmcweb references sdbusplus through subprojects/sdbusplus.wrap:
     *
https://github.com/openbmc/bmcweb
  *
sdbusplus is maintained under the OpenBMC organization:
     *
https://github.com/openbmc/sdbusplus
     *
https://github.com/openbmc/sdbusplus/blob/master/subprojects/stdexec.wrap
  *
sdbusplus in turn references stdexec through subprojects/stdexec.wrap :
     *
https://github.com/NVIDIA/stdexec

First, I would like to acknowledge and appreciate the work that has gone into this implementation. The intent of this note is not to question the quality of the code or the contributions made by NVIDIA, but rather to discuss whether there may be an opportunity to align this dependency more closely with OpenBMC’s long-term governance and maintenance model. Since stdexec is now part of a commonly consumed dependency path within OpenBMC, it may be worth considering whether a community-maintained approach could provide additional benefits, such as:

  *
Reduced risk from repository access, policy, or ownership changes outside the OpenBMC project
  *
Broader review and maintainer participation and long-term support
  *
Improved community ownership , transparency and reduce dependency risk

If there have already been discussions on this topic, or if there is a preferred roadmap for the dependency, I would greatly appreciate any references or guidance. My goal is simply to explore whether we can further strengthen the sustainability, transparency, and long-term maintainability of the OpenBMC dependency ecosystem as it continues to grow.

Thank you for your time and consideration. I look forward to hearing the community’s thoughts.

Best regards,

Chinmoy Dey


[-- Attachment #2: Type: text/html, Size: 7178 bytes --]

[Gentle Follow-up] [stdexec] Long-Term Ownership and Maintenance of stdexec Dependency

[Chinmoy Dey]

[-- Attachment #1: Type: text/plain, Size: 2229 bytes --]


Hi Team,

Just following up on my earlier email and resending it to make sure it hasn’t been missed.

I would appreciate it if you could please take a look when you get a chance.

Regards,
Chinmoy



> On 23 Jun 2026, at 5:59 PM, Chinmoy Dey <chinmoy@nexthop.ai> wrote:
> 
> Hi OpenBMC Community,
> 
> I would like to start a discussion around the long-term ownership and maintenance model for the stdexec dependency that is currently part of the OpenBMC dependency chain. As I understand it today:
> 
> bmcweb references sdbusplus through subprojects/sdbusplus.wrap:
> https://github.com/openbmc/bmcweb 
> sdbusplus is maintained under the OpenBMC organization:
> https://github.com/openbmc/sdbusplus 
> https://github.com/openbmc/sdbusplus/blob/master/subprojects/stdexec.wrap
> sdbusplus in turn references stdexec through subprojects/stdexec.wrap :
> https://github.com/NVIDIA/stdexec 
> First, I would like to acknowledge and appreciate the work that has gone into this implementation. The intent of this note is not to question the quality of the code or the contributions made by NVIDIA, but rather to discuss whether there may be an opportunity to align this dependency more closely with OpenBMC’s long-term governance and maintenance model. Since stdexec is now part of a commonly consumed dependency path within OpenBMC, it may be worth considering whether a community-maintained approach could provide additional benefits, such as:
> 
> Reduced risk from repository access, policy, or ownership changes outside the OpenBMC project
> Broader review and maintainer participation and long-term support
> Improved community ownership , transparency and reduce dependency risk
> If there have already been discussions on this topic, or if there is a preferred roadmap for the dependency, I would greatly appreciate any references or guidance. My goal is simply to explore whether we can further strengthen the sustainability, transparency, and long-term maintainability of the OpenBMC dependency ecosystem as it continues to grow.
> 
> Thank you for your time and consideration. I look forward to hearing the community’s thoughts.
> 
> Best regards,
> 
> Chinmoy Dey
> 
> 


[-- Attachment #2: Type: text/html, Size: 7581 bytes --]

Re: [Gentle Follow-up] [stdexec] Long-Term Ownership and Maintenance of stdexec Dependency

[Alexander Hansen]

[-- Attachment #1: Type: text/plain, Size: 4261 bytes --]

Hi Chinmoy,

why would we fork our dependency here ?

 > Reduced risk from repository access, policy, or ownership changes 
outside the OpenBMC project

What is meant by this? We are consuming the code from stdexec. How they 
do their governance or policy is maybe irrelevant to us as long as the 
license is compatible and the code is working ?

What is "risk of repository access" ? If the SRCREV is bumped in the 
yocto recipe, you can review any changes done to the project, right?

The recipe is here: meta-phosphor/recipes-extended/stdexec/stdexec_git.bb

If you build subprojects out of tree then meson will usually not fetch a 
new subproject revision unless you explicitly tell it to. So in each 
case you can review all code changes..

 > Broader review and maintainer participation and long-term support

If someone wants to review the changes to stdexec they can do so at 
https://github.com/NVIDIA/stdexec/pulls ?

What is preventing you from reviewing and long-term supporting stdexec 
via the normal github workflow?

 > Improved community ownership , transparency and reduce dependency risk

IMO ownership means understanding and maintaining the code. Who in the 
openbmc community is even working on stdexec?
When i look at the contributors, the only one i see from openbmc 
community is Patrick 
https://github.com/NVIDIA/stdexec/graphs/contributors?all=1

(maybe i am wrong and there are more people working on it ?)

Who should own and maintain this stdexec fork you are proposing?
And is the person you are proposing to maintain this qualified to do so?
What would be an example change to stdexec you see as required that 
cannot be done in the upstream repo and therefore would require 
forking/patching ?

Thanks,
Alexander

On 7/30/26 07:36, Chinmoy Dey wrote:
>
> Hi Team,
>
> Just following up on my earlier email and resending it to make sure it 
> hasn’t been missed.
>
> I would appreciate it if you could please take a look when you get a 
> chance.
>
> Regards,
> Chinmoy
>
>
>> On 23 Jun 2026, at 5:59 PM, Chinmoy Dey <chinmoy@nexthop.ai> wrote:
>>
>> Hi OpenBMC Community,
>>
>> I would like to start a discussion around the long-term ownership and 
>> maintenance model for the *|stdexec|* dependency that is currently 
>> part of the *OpenBMC* dependency chain. As I understand it today:
>>
>>  *
>>     |bmcweb| references |sdbusplus| through|subprojects/sdbusplus.wrap|:
>>      o
>>         https://github.com/openbmc/bmcweb
>>  *
>>     |sdbusplus| is maintained under the OpenBMC organization:
>>      o
>>         https://github.com/openbmc/sdbusplus
>>      o
>>         https://github.com/openbmc/sdbusplus/blob/master/subprojects/stdexec.wrap
>>  *
>>     |sdbusplus| in turn references |stdexec| through
>>     |subprojects/stdexec.wrap|||:
>>      o
>>         https://github.com/NVIDIA/stdexec
>>
>> First, I would like to acknowledge and appreciate the work that has 
>> gone into this implementation. The intent of this note is not to 
>> question the quality of the code or the contributions made by NVIDIA, 
>> but rather to discuss whether there may be an opportunity to align 
>> this dependency more closely with OpenBMC’s long-term governance and 
>> maintenance model. Since |stdexec| is now part of a commonly consumed 
>> dependency path within OpenBMC, it may be worth considering whether a 
>> community-maintained approach could provide additional benefits, such as:
>>
>>  *
>>     Reduced risk from repository access, policy, or ownership changes
>>     outside the OpenBMC project
>>  *
>>     Broader review and maintainer participation and long-term support
>>  *
>>     Improved community ownership , transparency and reduce dependency
>>     risk
>>
>> If there have already been discussions on this topic, or if there is 
>> a preferred roadmap for the dependency, I would greatly appreciate 
>> any references or guidance. My goal is simply to explore whether we 
>> can further strengthen the sustainability, transparency, and 
>> long-term maintainability of the OpenBMC dependency ecosystem as it 
>> continues to grow.
>>
>> Thank you for your time and consideration. I look forward to hearing 
>> the community’s thoughts.
>>
>> Best regards,
>>
>> Chinmoy Dey
>>
>>
>

[-- Attachment #2: Type: text/html, Size: 12993 bytes --]

Re: [stdexec] Long-Term Ownership and Maintenance of stdexec Dependency

[Patrick Williams]

[-- Attachment #1: Type: text/plain, Size: 3937 bytes --]

On Tue, Jun 23, 2026 at 12:29:03PM +0000, Chinmoy Dey wrote:
> Hi OpenBMC Community,
> 
> I would like to start a discussion around the long-term ownership and maintenance model for the stdexec dependency that is currently part of the OpenBMC dependency chain. As I understand it today:
> 
>   *
> bmcweb references sdbusplus through subprojects/sdbusplus.wrap:
>      *
> https://github.com/openbmc/bmcweb
>   *
> sdbusplus is maintained under the OpenBMC organization:
>      *
> https://github.com/openbmc/sdbusplus
>      *
> https://github.com/openbmc/sdbusplus/blob/master/subprojects/stdexec.wrap
>   *
> sdbusplus in turn references stdexec through subprojects/stdexec.wrap :
>      *
> https://github.com/NVIDIA/stdexec
> 
> First, I would like to acknowledge and appreciate the work that has gone into this implementation. The intent of this note is not to question the quality of the code or the contributions made by NVIDIA, but rather to discuss whether there may be an opportunity to align this dependency more closely with OpenBMC’s long-term governance and maintenance model. Since stdexec is now part of a commonly consumed dependency path within OpenBMC, it may be worth considering whether a community-maintained approach could provide additional benefits, such as:
> 
>   *
> Reduced risk from repository access, policy, or ownership changes outside the OpenBMC project
>   *
> Broader review and maintainer participation and long-term support
>   *
> Improved community ownership , transparency and reduce dependency risk
> 
> If there have already been discussions on this topic, or if there is a preferred roadmap for the dependency, I would greatly appreciate any references or guidance. My goal is simply to explore whether we can further strengthen the sustainability, transparency, and long-term maintainability of the OpenBMC dependency ecosystem as it continues to grow.
> 
> Thank you for your time and consideration. I look forward to hearing the community’s thoughts.

I didn't respond to this before because honestly it sounded like a
competitor to NVIDIA trying to assert a "we shouldn't use any software
from my competitor" stance.  Nexthop isn't even an OpenBMC contributor; why
should you have any influence on this?  At least sign the CCLA before
you try to "assert influence".

For background, stdexec was the reference implementation of P2300
(std::execution) during the standards process.  It is currently the only
complete implementation.  We are using it because it is a reference
implementation of a very useful aspect of C++26, which we have based
future async programming around.

The day GCC and Clang have a native P2300 support, we will start work to move
off stdexec and use the native support.  If you look at the way our
headers are structured it is even designed so that all stdexec usage is
replaceable with std::execution.

I don't see any cause for concern of using the stdexec library anymore
than I would have concern for using nlohmann::json (which is maintained
by a single person).  If for some reason NVIDIA moves the repository in
a direction that isn't useful for us we can always pin the SRCREV to a
point that does work for us, but I really don't foresee them doing that.

I'm the only one in OpenBMC (as far as I know) that has contributed to
stdexec and I sure don't want to maintain our own private fork of the
P2300 specification.  If you were to print it out, the specification is about
190 pages and the implementation is some expert level C++.  The primary
author is such a C++ expert that there is a primitive named after him
(niebloids) and was also the primary author of the std::ranges specification.
I'm not going to compete with that and I doubt anyone else in the project is
going to either.  Where the guy works shouldn't matter when his code
speaks for itself.

-- 
Patrick Williams

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 870 bytes --]