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 > > > > On Thu, 16 Jul 2026 at 12:29, Wei ZHOU <[email protected]> wrote: > > > > > > Hi Abhishek, > > > > > > Thanks for sharing your thoughts. I understand your concern, and I > agree > > > that we should continue looking for ways to reduce the growing PR > > backlog. > > > > > > One thing I'd like to clarify is that 4.23 is a regular feature > release, > > > with a primary focus on new features and improvements. Most bug-fix PRs > > are > > > instead targeted for the 4.22.2.0 or 4.20.4.0 milestones, which are the > > > next LTS releases. > > > > > > Regarding the PRs that were moved out of the 4.23.0 milestone, the main > > > reason was not necessarily the risk of the changes themselves. Many of > > them > > > were simply not ready for review and testing before the code freeze. > > > According to our merge policy, every PR must be adequately reviewed and > > > tested before it can be merged. If a PR is still work in progress, > > awaiting > > > review, or has not yet been sufficiently validated, it cannot > > realistically > > > be included in the release. > > > > > > The community also has limited QA resources. This is especially > > challenging > > > for new features and large improvements, which typically require > > > considerably more effort to review and test than bug fixes. As a > result, > > > some PRs had to be deferred even though they are valuable additions. > The > > > deferred PRs have been moved to the 4.24.0 milestone: > > > > > > https://github.com/apache/cloudstack/pulls?q=is%3Aopen+is%3Apr+milestone%3A4.24.0 > > > > > > Hopefully, this provides enough visibility for authors and reviewers to > > > continue working on them early in the next development cycle. > > > > > > I agree that reducing the PR backlog is important, and I think the best > > way > > > to achieve that is to encourage PR authors to get their changes ready > for > > > review and testing earlier in the release cycle, while also attracting > > more > > > reviewers and testers from the community. > > > > > > Thanks again for raising the discussion. > > > > > > > > > > > > Kind regards, > > > > > > Wei > > > > > > > > > > > >
