4:48 a.m.
*
50 is an arbitrary number, but it seems reasonable
I think this is a great proposal and surely it is a community-oriented idea. +1 to all
your 6 points. However, I believe that the reasonable PR number depends on how many PRs
are opened daily/weekly.
What about focusing more on the time limit of a PR? Should we try to close/merge within 6
months maybe (unless exceptional reasons)? Or at least move it to draft?
What about having a stricter policy on keeping a PR open for longer than 2 months or so?
Old PRs create extra work: resolving conflicts + rebasing + retesting + reviewing. And
that should be avoided whenever possible.
I will try to make some workflow examples (which may not fit well with WildFly):
*
Is it still open because there is an implementation choice to make? Could we close it and
discuss it in a wildfly-proposal before?
*
Are we still waiting for input ? Let's give a timeline to provide the input otherwise
let's close the PR (for the moment) and reopen it when the input is provided, and in
the meanwhile somebody else could work on the issue and open a new PR for it.
*
A Feature is very big and needs extra time: what about splitting the Feature PR into 2 or
3 'faster' PRs (when possible) so that we can at least merge the
'backbone' part of the feature and then adding the other parts (when modularity is
possible)?
Ideally WFLY Jira workflow might need a new 'Pull request parked' status next to
'Pull request sent' for PRs waiting for inputs for a long time or having
'missing-reqs' / 'core-upgrade-needed' label for a while.
Marco Sappe' Griot
________________________________
From: Brian Stansberry <bstansberry(a)gmail.com>
Sent: Thursday, January 22, 2026 7:56 PM
To: wildfly-dev(a)lists.jboss.org <wildfly-dev(a)lists.jboss.org>
Subject: [EXTERNAL] [wildfly-dev] 50 or less open PRs in wildfly/wildfly queue
I'd love it if by the end of WF 40 development in April we could get
the PR count in https://github.com/wildfly/wildfly/pulls down to 50
and then keep it there going forward.
We spent much of the last year or two at around 100, which is not good
for contributors or for maintainers.
50 is an arbitrary number, but it seems reasonable. For example, it
would allow us to have in the queue:
10 Feature PRs
5 Dependabot PRs
10 misc non-Feature PRs that are quickly moving through a
review[/update/review]/merge cycle.
10 more difficult non-Feature PRs that are taking more than a couple
weeks to get in shape for merging
10 short term drafts where people using the PR queue to gather feedback on WIP
Plus a 5 PR buffer for when there are randomly more of some of those types.
The mix could of course be different over time.
Things to do to get there:
1) My favorite -- get our Features completed. We currently have 24 PRs
labeled as Feature. That is far too many.
2) My second favorite -- help review and merge PRs, particularly
non-Feature PRs, and including old ones.
3) Go on an exercise to get various PRs that fell into cracks merged
or closed. I made an effort on that in Nov/Dec which is one reason the
queue is now 73.
4) PRs that are not mergeable because they are missing some
requirement (say a WF Core upgrade) must be in 'Draft' state until
whatever they are waiting on is in process to become available (e.g.
the required change in Core is merged so we know it will be available
within a couple weeks.). Those drafts should become mergeable or be
closed within two or three weeks.
5) Resist the urge to use the PR queue to gather feedback on WIP. Are
you really looking for input from random people, or do you have
particular people in mind? If the latter, ask those people to look at
your branch in your personal repo. I'm not saying never open draft PRs
like this but don't leave them open for long periods, and definitely
not if work has halted for some reason.
6) Be willing to say no and close a PR if you are the component lead
for the relevant area.
WDYT?
Best regards,
Brian
_______________________________________________
wildfly-dev mailing list -- wildfly-dev(a)lists.jboss.org
To unsubscribe send an email to wildfly-dev-leave(a)lists.jboss.org
Privacy Statement: https://www.redhat.com/en/about/privacy-policy
List Archives:
https://lists.jboss.org/archives/list/wildfly-dev@lists.jboss.org/message...
Unless otherwise stated above:
IBM Italia S.p.A.
Sede Legale: Circonvallazione Idroscalo - 20054 Segrate (MI)
Cap. Soc. euro 247.656.998.20
C. F. e Reg. Imprese MI 01442240030 - Partita IVA 10914660153
Società con unico azionista
Società soggetta all'attività di direzione e coordinamento di International Business
Machines Corporation