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

--BkS8mLrWolNTLwwq
Content-Type: text/plain; charset=utf-8
Content-Disposition: inline
Content-Transfer-Encoding: quoted-printable

On Tue, Jun 23, 2026 at 12:29:03PM +0000, Chinmoy Dey wrote:
> Hi OpenBMC Community,
>=20
> I would like to start a discussion around the long-term ownership and mai=
ntenance model for the stdexec dependency that is currently part of the Ope=
nBMC dependency chain. As I understand it today:
>=20
>   *
> 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
>=20
> 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 qu=
ality of the code or the contributions made by NVIDIA, but rather to discus=
s whether there may be an opportunity to align this dependency more closely=
 with OpenBMC=E2=80=99s long-term governance and maintenance model. Since s=
tdexec is now part of a commonly consumed dependency path within OpenBMC, i=
t may be worth considering whether a community-maintained approach could pr=
ovide additional benefits, such as:
>=20
>   *
> 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
>=20
> If there have already been discussions on this topic, or if there is a pr=
eferred roadmap for the dependency, I would greatly appreciate any referenc=
es or guidance. My goal is simply to explore whether we can further strengt=
hen the sustainability, transparency, and long-term maintainability of the =
OpenBMC dependency ecosystem as it continues to grow.
>=20
> Thank you for your time and consideration. I look forward to hearing the =
community=E2=80=99s 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
=66rom my competitor" stance.  Nexthop isn't even an OpenBMC contributor; w=
hy
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 mo=
ve
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 abo=
ut
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 specificatio=
n.
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.

--=20
Patrick Williams

--BkS8mLrWolNTLwwq
Content-Type: application/pgp-signature; name=signature.asc

-----BEGIN PGP SIGNATURE-----

iQJPBAABCAA5FiEEBGD9ii4LE9cNbqJBqwNHzC0AwRkFAmps8UobFIAAAAAABAAO
bWFudTIsMi41KzEuMTIsMiwyAAoJEKsDR8wtAMEZ+o0P+wTPBtklCAcvB6/H2BN9
+XYfZtN6On6UiNvMwcuZ++SnTwrIgujWOxAP0caMJfgGcAosq80ggi9tSvXbInCD
RceDDe7kyBkIxbvNpNBr/kFmvWni2kqGw0CA7xidjgqe+dnFejadqJmoIqDBlwqv
ZWpcA07q/Oi3+Vef0RFjCMvhe44vm0ufGluAxlWPV8bWgx1JKrLmL5FR8hKSVIda
e5ndgEaerWCtZB9ZAkRVcfvxaE+/YGQAhJi1rHfAXl4O9msFSxsTrCwUQ7xGepWB
gw4z1coOW2Ll79LUgF119ueJx7taOW4GIejF1u/PFyIbJUKFtzEi2oyC70DDIfSl
1jpxXOh9csL+JQnG+kDMmX67NocTHOemrGAimg/3f5U1+i2cKLyy6MbS+yLH2N+8
Pws/1rJI3yqqq8FQNAPmcJdT0kHdE5CCpS3GlOR2NiFFbeREs7h3CXIujR0lP4wK
8UhtrqGViBs5Jz7uqKyvu3s/eMrirzbH4Lpu1l7a4r/TEvDifol2lCqEVjuXxl2h
t4yaV7K+qfZkN/dNwHJ/itFurkXHvEEE2qsqbWk7h8j5evEf0S/cufl65p5rnpN2
dV22+XFcHjtOOoZfdG5UDWaN+dj3y/XMQS0Gz+IJvFmhlxH/RZkjKv6qfh+f+50V
4YAfzl0OQR0pYrCk4aT3HIO1
=9EV3
-----END PGP SIGNATURE-----

--BkS8mLrWolNTLwwq--