Op 03-11-2026 om 14:52 schreef Nicolas Vazquez:
Thanks Daan for raising this, just sharing my 2 cents:
I don't think the 4-week inactivity period for merging PRs is a good idea.
I agree with Slavka that this approach can be risky, also considering that
we do have release managers actively triaging PRs and issues to be included
in the release.
I do not disagree with either Slavka or Nicolas, but I do understand
Dahn's point. PRs are being opened faster than we can test and merge them.
Our current testing is based on running various tests, but aren't those
tests becoming outdated?
Recently I have been testing most PRs with either Claude Fable (90%) or
ChatGPT Astra 6 (10%) and the results have been amazing.
In the hands of the right developer who understands CloudStack you can
write amazing features for CloudStack, way faster then they can be
tested by a human.
I do think we need LLMs here to test PRs and do triage, but then:
- CloudStack is open source, who is going to pay for the tokens?
- Do we trust LLMs enough to do the testing?
At the current rate we will never get the work done to triage and test
all PRs, so my suggestion would be:
- We close all PRs which are open for more than X months, with a proper
message that the author is free to re-open them
- We start to allow testing using LLMs only
- The human is still responsible for what gets merged and submitted
We might need to have a shorter release cycle to make testing of the
releases easier as less things go in. But we can't continue like this.
LLMs have changed the software development world fundamentally.
Wido
In these cases I would expect release managers to review the PRs and decide
whether additional reviews are needed or whether a PR can be merged at a
certain point, instead of leaving it to the PR author to perform a
self-merge.
Regards,
Nicolas Vazquez
El mar, 3 nov 2026 a las 8:42, Slavka Peleva (<[email protected]>)
escribió:
Hi all,
First of all, I’d like to thank Daan for raising this important question.
Recently, we’ve seen instances where some maintainers take matters into
their own hands and self-merge their code. This can definitely discourage
committers and external contributors, creating a feeling of double
standards—where some feel 'left behind' or treated differently than others.
It is crucial that we establish strict, fair rules so that everyone,
regardless of their official status in the project, feels valued and plays
by the same rules.
Regarding the specific proposal for a 4-week self-merge option, while I
completely share the frustration about PRs stalling and want to find a way
to speed things up, I feel this approach is too risky for a few reasons:
1. *Blind spots in testing:* We all have blind spots regarding our own
code. We test based on the same assumptions we used to write it, making it
very easy to miss critical edge cases or integration issues that a fresh
pair of eyes would catch.
2. *Risk of quality and security loopholes:* Allowing self-merges
after inactivity could unintentionally create a loophole. Low-quality or
problematic code could slip through simply because a PR managed to 'wait
out' the 4-week window during a quiet period in the community.
Since we are a global, asynchronous community working across different
time zones, synchronous meetings are not realistic. Instead, we could look
at how other distributed open-source projects improve review velocity
fairly and transparently using asynchronous methods:
- *Automated Reviewer Assignment (CODEOWNERS):* Automatically tagging
specific maintainers based on the changed files, so the responsibility for
the review is clearly assigned and doesn't fall into a void.
- *Stale Bots & Reminders:* Automated pings in GitHub/Mailing lists
when a PR has been inactive for more than two weeks, bringing the focus
back to forgotten PRs.
- *Asynchronous Triage Queue:* Using automated labels (like
needs-review or prioritizing by age) so maintainers can easily spot and
unblock the oldest pending PRs whenever they log in, regardless of their
time zone.
This way, we can make the process faster, fair, and more transparent for
everyone, while still keeping our codebase secure and thoroughly reviewed.
Best regards,
Slavka
On Tue, 3 Nov 2026 at 10:46, Daan Hoogland via private <
[email protected]> wrote:
People,
Since very early in the project we had maintained the standard that any
PR will need
- two reviews
- at minimal one review containing a test report
We also stated some exception;
- text only changes
- changes to test code
- changes to ci code
Lately, mostly with the involvement of storage vendors we had let that
go. I remember that we would allow PRs that need specific hard- or
software, if the vendor would add a test report to their own PR (citation
needed!)
Now there are two amendment that I want to make to that practice:
- I want formulising it in some textual form in our git repo.
- I want to add that users that tested their own code can merge it if
after a period of four weeks nobody else tested it to prove some flaw and
made an objection.
Especially the last one is a significant change. The intention is for
users to be able to get through the large backlog we have and have fixes
and enhancements that are vital to them merged.
thoughts?
regards,
