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

Alexander Hansen <[email protected]> Fri, 31 Jul 2026 11:00:25 +0200
Newsgroups org.ozlabs.lists.openbmc
Message-ID <[email protected]>
This is a multi-part message in MIME format.
--------------J0x1Mn9wHnBEMbFTI0z3N0ol
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 8bit

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 <[email protected]> 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
>>
>>
>
--------------J0x1Mn9wHnBEMbFTI0z3N0ol
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: 8bit

<!DOCTYPE html>
<html>
  <head>
    <meta http-equiv="Content-Type" content="text/html; charset=UTF-8">
  </head>
  <body>
    <p>Hi Chinmoy,<br>
      <br>
      why would we fork our dependency here ?<br>
      <br>
      &gt; Reduced risk from repository access, policy, or ownership
      changes outside the OpenBMC project<br>
      <br>
      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 ?<br>
      <br>
      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?<br>
      <br>
      The recipe is here:
      meta-phosphor/recipes-extended/stdexec/stdexec_git.bb<br>
      <br>
      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..<br>
      <br>
      &gt; Broader review and maintainer participation and long-term
      support<br>
      <br>
      If someone wants to review the changes to stdexec they can do so
      at <a class="moz-txt-link-freetext" href="https://github.com/NVIDIA/stdexec/pulls">https://github.com/NVIDIA/stdexec/pulls</a> ?<br>
      <br>
      What is preventing you from reviewing and long-term supporting
      stdexec via the normal github workflow?<br>
      <br>
      &gt; Improved community ownership , transparency and reduce
      dependency risk<br>
      <br>
      IMO ownership means understanding and maintaining the code. Who in
      the openbmc community is even working on stdexec?<br>
      When i look at the contributors, the only one i see from openbmc
      community is Patrick
      <a class="moz-txt-link-freetext" href="https://github.com/NVIDIA/stdexec/graphs/contributors?all=1">https://github.com/NVIDIA/stdexec/graphs/contributors?all=1</a>  <br>
      <br>
      (maybe i am wrong and there are more people working on it ?)<br>
      <br>
      Who should own and maintain this stdexec fork you are proposing?<br>
      And is the person you are proposing to maintain this qualified to
      do so?<br>
      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 ?<br>
      <br>
      Thanks,<br>
      Alexander<br>
      <br>
    </p>
    <div class="moz-cite-prefix">On 7/30/26 07:36, Chinmoy Dey wrote:<br>
    </div>
    <blockquote type="cite"
      cite="mid:[email protected]">
      <meta http-equiv="content-type" content="text/html; charset=UTF-8">
      <div><br id="lineBreakAtBeginningOfMessage">
        <div>
          <p class="p1"><span style="font-size: 14px;">Hi Team,</span></p>
          <p class="p1"><span style="font-size: 14px;">Just following up
              on my earlier email and resending it to make sure it
              hasn’t been missed.</span></p>
          <p class="p1"><span style="font-size: 14px;">I would
              appreciate it if you could please take a look when you get
              a chance.</span></p>
          <p class="p1"><span style="font-size: 14px;">Regards,<br>
              Chinmoy</span></p>
          <p class="p1"><br>
          </p>
          <blockquote type="cite">
            <div>On 23 Jun 2026, at 5:59 PM, Chinmoy Dey
              <a class="moz-txt-link-rfc2396E" href="mailto:[email protected]">&lt;[email protected]&gt;</a> wrote:</div>
            <br class="Apple-interchange-newline">
            <div>
              <meta http-equiv="Content-Type"
                content="text/html; charset=UTF-8">
              <div>
                <p dir="ltr" class="p1"
                  style="text-align: left; text-indent: 0px;"><span
style="font-family: Aptos, Arial, Helvetica, sans-serif; font-size: 14pt;">Hi
                    OpenBMC Community,</span></p>
                <p class="p1"
                  style="text-align: left; text-indent: 0px;"><span
style="font-family: Aptos, Arial, Helvetica, sans-serif; font-size: 14pt;">I
                    would like to start a discussion around the
                    long-term ownership and maintenance model for the
                  </span><span
style="font-family: Aptos, Arial, Helvetica, sans-serif; font-size: 14pt; color: rgb(81, 167, 249);"><b><code>stdexec</code></b></span><span
style="font-family: Aptos, Arial, Helvetica, sans-serif; font-size: 14pt;"> dependency
                    that is currently part of the </span><span
style="font-family: Aptos, Arial, Helvetica, sans-serif; font-size: 14pt; color: rgb(81, 167, 249);"><b>OpenBMC</b></span><span
style="font-family: Aptos, Arial, Helvetica, sans-serif; font-size: 14pt;"> dependency
                    chain. As I understand it today:</span></p>
                <ul style="text-align: left;">
                  <li
style="font-family: Aptos, Arial, Helvetica, sans-serif; font-size: 14pt;">
                    <div><span style="color: rgb(81, 167, 249);"><code>bmcweb</code></span> references
                      <span style="color: rgb(81, 167, 249);"><code>sdbusplus</code></span> through<span
                        style="color: rgb(81, 167, 249);">
                        <code>subprojects/sdbusplus.wrap</code></span>:</div>
                  </li>
                  <ul
data-editing-info="{&quot;applyListStyleFromLevel&quot;:true}"
                    style="text-align: left; list-style-type: circle;">
                    <li
style="font-family: Aptos, Arial, Helvetica, sans-serif; font-size: 14pt;">
                      <div><a href="https://github.com/openbmc/bmcweb"
data-outlook-id="d8c2b49c-07aa-43d2-acc3-e2c8c7768819"
                          moz-do-not-send="true"
                          class="moz-txt-link-freetext">https://github.com/openbmc/bmcweb</a> </div>
                    </li>
                  </ul>
                  <li
style="font-family: Aptos, Arial, Helvetica, sans-serif; font-size: 14pt;">
                    <div><span style="color: rgb(81, 167, 249);"><code>sdbusplus</code></span> is
                      maintained under the OpenBMC organization:</div>
                  </li>
                  <ul
data-editing-info="{&quot;applyListStyleFromLevel&quot;:true}"
                    style="text-align: left; list-style-type: circle;">
                    <li
style="font-family: Aptos, Arial, Helvetica, sans-serif; font-size: 14pt;">
                      <div><a
                          href="https://github.com/openbmc/sdbusplus"
data-outlook-id="1fe0a3a9-3766-408b-8060-f3453e915191"
                          moz-do-not-send="true"
                          class="moz-txt-link-freetext">https://github.com/openbmc/sdbusplus</a> </div>
                    </li>
                    <li
style="font-family: Aptos, Arial, Helvetica, sans-serif; font-size: 14pt;">
                      <div dir="ltr" style=""><a
href="https://github.com/openbmc/sdbusplus/blob/master/subprojects/stdexec.wrap"
data-outlook-id="1447a88a-4fa7-4732-b205-d105cb87620c"
                          moz-do-not-send="true"
                          class="moz-txt-link-freetext">https://github.com/openbmc/sdbusplus/blob/master/subprojects/stdexec.wrap</a></div>
                    </li>
                  </ul>
                  <li
style="font-family: Aptos, Arial, Helvetica, sans-serif; font-size: 14pt;">
                    <div><span style="color: rgb(81, 167, 249);"><code>sdbusplus</code></span> in
                      turn references
                      <span style="color: rgb(81, 167, 249);"><code>stdexec</code></span> through
                      <span style="color: rgb(81, 167, 249);">
                        <code>subprojects/stdexec.wrap</code></span><code>
                      </code>:</div>
                  </li>
                  <ul
data-editing-info="{&quot;applyListStyleFromLevel&quot;:true}"
                    style="text-align: left; list-style-type: circle;">
                    <li
style="font-family: Aptos, Arial, Helvetica, sans-serif; font-size: 14pt;">
                      <div><a href="https://github.com/NVIDIA/stdexec"
data-outlook-id="65d6a77f-f757-46fc-9226-94383fc74d4e"
                          moz-do-not-send="true"
                          class="moz-txt-link-freetext">https://github.com/NVIDIA/stdexec</a> </div>
                    </li>
                  </ul>
                </ul>
                <p class="p1"
                  style="text-align: left; text-indent: 0px;"><span
style="font-family: Aptos, Arial, Helvetica, sans-serif; font-size: 14pt;">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 </span><span
style="font-family: Aptos, Arial, Helvetica, sans-serif; font-size: 14pt; color: rgb(81, 167, 249);"><code>stdexec</code></span><span
style="font-family: Aptos, Arial, Helvetica, sans-serif; font-size: 14pt;"> is
                    now part of a commonly consumed dependency path
                    within </span><span
style="font-family: Aptos, Arial, Helvetica, sans-serif; font-size: 14pt; color: rgb(81, 167, 249);">OpenBMC</span><span
style="font-family: Aptos, Arial, Helvetica, sans-serif; font-size: 14pt;">,
                    it may be worth considering whether a
                    community-maintained approach could provide
                    additional benefits, such as:</span></p>
                <ul style="text-align: left;">
                  <li
style="font-family: Aptos, Arial, Helvetica, sans-serif; font-size: 14pt;">
                    <div>Reduced risk from repository access, policy, or
                      ownership changes outside the OpenBMC project</div>
                  </li>
                  <li
style="font-family: Aptos, Arial, Helvetica, sans-serif; font-size: 14pt;">
                    <div dir="ltr" style="font-size: 18.666666px;"><span
                        style="background-color: rgb(255, 255, 255);">Broader
                        review and maintainer participation and
                        long-term support</span></div>
                  </li>
                  <li
style="font-family: Aptos, Arial, Helvetica, sans-serif; font-size: 14pt;">
                    <div>Improved community ownership , transparency and
                      reduce <span
style="font-size: 18.666666px; background-color: rgb(255, 255, 255);">
                        dependency risk</span></div>
                  </li>
                </ul>
                <p class="p2"
                  style="text-align: left; text-indent: 0px;"><span
style="font-family: Aptos, Arial, Helvetica, sans-serif; font-size: 14pt;">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.</span></p>
                <p class="p1"
                  style="text-align: left; text-indent: 0px;"><span
style="font-family: Aptos, Arial, Helvetica, sans-serif; font-size: 14pt;">Thank
                    you for your time and consideration. I look forward
                    to hearing the community’s thoughts.</span></p>
                <p class="p1"
                  style="text-align: left; text-indent: 0px;"><span
style="font-family: Aptos, Arial, Helvetica, sans-serif; font-size: 12pt;">Best
                    regards,</span></p>
                <p class="p1"
                  style="text-align: left; text-indent: 0px;"><span
style="font-family: Aptos, Arial, Helvetica, sans-serif; font-size: 12pt;">Chinmoy
                    Dey</span></p>
                <div dir="ltr"
style="font-family: Aptos, Arial, Helvetica, sans-serif; font-size: 12pt;">
                  <br>
                </div>
                <div id="ms-outlook-mobile-signature" dir="ltr"
                  style="color: inherit; background-color: inherit;">
                </div>
              </div>
            </div>
          </blockquote>
        </div>
        <br>
      </div>
    </blockquote>
  </body>
</html>

--------------J0x1Mn9wHnBEMbFTI0z3N0ol--