<html><head>
<meta http-equiv="Content-Type" content="text/html; charset=utf-8">
  </head>
  <body>
    <p>Hi,</p>
    <p>At the very same time at the PTG we discussed this on the Release
      Management session [1] as well. To release deliverables without
      significant content is not ideal and this came up in previous
      discussions as well. On the other hand unfortunately this is the
      most feasible solution from release management team perspective
      especially because the team is quite small (new members are
      welcome! feel free to join the release management team! :)). <br>
    </p>
    <p>To change to independent release model is an option for some
      cases, but not for every project. (It is less clear for consumers
      what version is/should be used for which series; Fixing problems
      that comes up in specific stable branches, is not possible;
      testing the deliverable against a specific stable branch
      constraints is not possiblel; etc.)<br>
    </p>
    <p>See some other comments inline.<br>
      <br>
      [1] <a class="moz-txt-link-freetext" href="https://etherpad.opendev.org/p/april2022-ptg-rel-mgt#L44">https://etherpad.opendev.org/p/april2022-ptg-rel-mgt#L44</a><br>
    </p>
    <p>Előd</p>
    <pre class="moz-signature" cols="72">
</pre>
    <div class="moz-cite-prefix">On 2022. 04. 19. 18:01, Michael Johnson
      wrote:<br>
    </div>
    <blockquote type="cite" cite="mid:CAMH0MgK=B+qXH8Up8unX--utXewDinOjQ-=SorCfAmexU93ywQ@mail.gmail.com">
      <pre class="moz-quote-pre" wrap="">Comments inline.

Michael

On Tue, Apr 19, 2022 at 6:34 AM Slawek Kaplonski <a class="moz-txt-link-rfc2396E" href="mailto:skaplons@redhat.com"><skaplons@redhat.com></a> wrote:
</pre>
      <blockquote type="cite">
        <pre class="moz-quote-pre" wrap="">
Hi,


During the Zed PTG sessions in the TC room we were discussing some ideas how we can improve project governance.

One of the topics was related to the projects which don't really have any changes in the cycle. Currently we are forcing to do new release of basically the same code when it comes to the end of the cycle.

Can/Should we maybe change that and e.g. instead of forcing new release use last released version of the of the repo for new release too?
</pre>
      </blockquote>
      <pre class="moz-quote-pre" wrap="">
In the past this has created confusion in the community about if a
project has been dropped/removed from OpenStack. That said, I think
this is the point of the "independent" release classification.</pre>
    </blockquote>
    Yes, exactly as Michael says.<br>
    <blockquote type="cite" cite="mid:CAMH0MgK=B+qXH8Up8unX--utXewDinOjQ-=SorCfAmexU93ywQ@mail.gmail.com">
      <pre class="moz-quote-pre" wrap="">
</pre>
      <blockquote type="cite">
        <pre class="moz-quote-pre" wrap="">If yes, should we then automatically propose change of the release model to the "independent" maybe?
</pre>
      </blockquote>
      <pre class="moz-quote-pre" wrap="">
Personally, I would prefer to send an email to the discuss list
proposing the switch to independent. Patches can sometimes get merged
before everyone gets to give input. Especially since the patch would
be proposed in the "releases" project and may not be on the team's
dashboards.</pre>
    </blockquote>
    The release process catches libraries only (that had no merged
    change), so the number is not that huge, sending a mail seems to be
    a fair option.<br>
    <br>
    (The process says: "Evaluate any libraries that did not have any
    change merged over the
    cycle to see if it is time to <a class="reference external" href="https://releases.openstack.org/reference/release_models.html#openstack-related-libraries">transition
      them to the independent release
      model</a>.<br>
    Note: client libraries (and other libraries strongly tied to another
    deliverable) should generally follow their parent deliverable
    release
    model, even if they did not have a lot of activity themselves).")
    <blockquote type="cite" cite="mid:CAMH0MgK=B+qXH8Up8unX--utXewDinOjQ-=SorCfAmexU93ywQ@mail.gmail.com">
      <pre class="moz-quote-pre" wrap="">
</pre>
      <blockquote type="cite">
        <pre class="moz-quote-pre" wrap="">What would be the best way how Release Management team can maybe notify TC about such less active projects which don't needs any new release in the cycle? That could be one of the potential conditions to check project's health by the TC team.
</pre>
      </blockquote>
      <pre class="moz-quote-pre" wrap="">
It seems like this would be a straight forward script to write given
we already have tools to capture the list of changes included in a
given release.</pre>
    </blockquote>
    <p>There are a couple of good signals already for TC to catch
      inactive projects, like the generated patches that are not merged,
      for example:</p>
    <p><a class="moz-txt-link-freetext" href="https://review.opendev.org/q/topic:reno-yoga+is:open">https://review.opendev.org/q/topic:reno-yoga+is:open</a><br>
      <a class="moz-txt-link-freetext" href="https://review.opendev.org/q/topic:create-yoga+is:open">https://review.opendev.org/q/topic:create-yoga+is:open</a><br>
<a class="moz-txt-link-freetext" href="https://review.opendev.org/q/topic:add-xena-python-jobtemplates+is:open">https://review.opendev.org/q/topic:add-xena-python-jobtemplates+is:open</a><br>
      <br>
      (Note that in the past not merged patches caused issues and
      discussing with the TC resulted a suggestion to force-merge them
      to avoid future issues)<br>
    </p>
    <blockquote type="cite" cite="mid:CAMH0MgK=B+qXH8Up8unX--utXewDinOjQ-=SorCfAmexU93ywQ@mail.gmail.com">
      <pre class="moz-quote-pre" wrap="">
</pre>
      <blockquote type="cite">
        <pre class="moz-quote-pre" wrap="">Another question is related to the projects which aren't really active and are broken during the final release time. We had such problem in the last cycle, see [1] for details. Should we still force pushing fixes for them to be able to release or maybe should we consider deprecation of such projects and not to release it at all?
</pre>
      </blockquote>
      <pre class="moz-quote-pre" wrap="">
In the past we have simply not released projects that are broken and
don't have people actively working on fixing them. It has been a
signal to the community that if they value the project they need to
contribute to it.</pre>
    </blockquote>
    <p>Yes, that's a fair point, too, maybe those broken deliverables
      should not be released at all. I'm not sure, but that might cause
      another issues for release management tooling, though...</p>
    <p>Besides, during our PTG session we came to the conclusion that we
      need another step in our process: <br>
      * "<span class="author-a-z76zuz70zz90zm2z76z5qbz74zz71zz68z4lj">propose
        DNM changes on every repository by RequirementsFreeze (5 weeks
        before final release) to check that tests are still passing with
        the current set of dependencies"<br>
        Hopefully this will catch broken things well in advance.<br>
      </span></p>
    <blockquote type="cite" cite="mid:CAMH0MgK=B+qXH8Up8unX--utXewDinOjQ-=SorCfAmexU93ywQ@mail.gmail.com">
      <pre class="moz-quote-pre" wrap="">
</pre>
      <blockquote type="cite">
        <pre class="moz-quote-pre" wrap="">[1] <a class="moz-txt-link-freetext" href="http://lists.openstack.org/pipermail/openstack-discuss/2022-March/027864.html">http://lists.openstack.org/pipermail/openstack-discuss/2022-March/027864.html</a>


--

Slawek Kaplonski

Principal Software Engineer

Red Hat
</pre>
      </blockquote>
      <pre class="moz-quote-pre" wrap="">
</pre>
    </blockquote>
  </body>
</html>