Hi Abhishek, Thanks for sharing your thoughts. I agree that we should continue to think about how to improve the release process.
For 4.23.0, I was quite ambitious and initially added a large number of pull requests and issues to the milestone. Some of them were also moved from the 4.22.0 milestone after the 4.22 release. When I reviewed the milestone on 29th June 2026, there were still more than 50 pull requests remaining. Since we were approaching the code freeze, I gradually moved some items to 4.24.0 due to inactivity, lack of review or updates. For bug fixes that were not critical for 4.23.0, I moved some to 4.22.2 or 4.20.4. I notified authors for some PRs, although I realize I did not do so consistently for every case. I would like to clarify that being included in a milestone does not necessarily mean a PR will finally be included in the release. Similarly, once a PR is moved out of the milestone, it does not mean the contribution is rejected; it simply means it is unlikely to make this specific release. If a PR is ready for merge and meets the merge criteria, we will of course consider it regardless of whether it is currently listed in the milestone. In my view, the milestone is mainly a management tool for the release manager (some RMs may use GitHub projects or other approaches instead). Fabricio and I have shared and updated the release timeline through the dev/users mailing lists. If contributors believe their PRs should be included in the release, I would encourage them to proactively follow up and help drive the required reviews, testing, and updates. We are happy to help unblock issues, but ultimately the PR author is the best person to push their contribution forward. I also want to appreciate the NetApp contributors, who have been very active in driving their PRs toward inclusion in the 4.23.0 release. For future releases, I think your suggestion about keeping items unplanned initially and only moving them into the release scope after they are evaluated is worth discussing. It may help set clearer expectations and reduce surprises closer to the release date. Kind regards, Wei On Thu, Jul 16, 2026 at 4:18 PM Abhishek Kumar <[email protected]> wrote: > Hi Wei, > > I uderstand the special cases and RM's discretion. My major point of > concern is can we be less conservative in non-LTS releases to allow > contributions from individuals who in most cases may not have support of > peer reviews and manual QA. > > I can surely share some examples in private which could have been included. > Maybe it would be better to move on and focus on the release for now. > > I do have a suggestion maybe for future, we keep all items as unplanned at > the time release planning and only consider adding those items which > genuinely seem fit to be included. This will make onus fall on the > contributor to ask RM for their contribution to be included. Currently, one > may see his/her PR present in the milestone early on but then suddenly > around release they get moved out. > > Regards, > > > Abhishek Kumar > > On Thu, 16 Jul, 2026, 13:45 Wei ZHOU, <[email protected]> wrote: > > > Hi Abhishek, > > > > Thanks for the feedback. I understand your point, and I agree that we > > should strive to be more transparent when PRs are moved out of a > milestone. > > > > The PR you mentioned is a bit of a special case. We were very close to > the > > code freeze, the change itself was small and low impact, and it had at > > least been tested by the author. It was also not the only exception - > there > > were other small PRs merged on the last day before the code freeze under > > similar circumstances. Ultimately, these decisions rely on the release > > managers' experience and judgment, taking into account the scope of the > > change, the potential risk, the level of review, and the time remaining > > before the release. The smoke test results on the 4.23 health check PR on > > various hypervisors look fine. That said, I agree we should try to avoid > > these last-minute exceptions in the future. > > > > Out of curiosity, are there any specific PRs that you think should have > > made it into the 4.23 release? It would be useful to discuss those > examples > > and see whether we could improve the process for future releases. > > Kind regards, > > Wei > > > > > > On Thu, Jul 16, 2026 at 9:37 AM Abhishek Kumar <[email protected]> > > wrote: > > > > > Thanks Wei. I understand the constraints, but overall, I feel it is > > > all about subjectivity and convenience. > > > Just for an example, this PR > > > https://github.com/apache/cloudstack/pull/13613 was merged within 2 > > > hours of creation. Approved by one of the RMs for merging. No > > > integration tests (though they wouldn't help much in this case). I > > > don't see any manual test reported in the PR either. > > > Definitely, we can not include all PRs, but I feel that when they are > > > moved out of a milestone, it would be better to give some reason. > > > Maybe it is my problem and my expectations are a bit high around this. > > > > > > Regards, > > > Abhishek > > > >
