Moving WildFly Elytron to Java 17
by Darran Lofthouse
Now that WildFly Core is built for Java 17 I would like to move WildFly
Elytron to Java 17 as well from our next releases for WildFly (2.7.x +).
Would this cause any issues for other projects that depend on WildFly
Elytron?
It should not affect Undertow as we use the Elytron Web project for
integration, maybe JBoss Remoting but also others with an Elytron
dependency so let me know if this would be an issue for your project.
--
Darran Lofthouse
Red Hat <https://www.redhat.com/>
darran.lofthouse(a)jboss.com
<https://www.redhat.com/>
2 months, 1 week
Use of the 'org.wildfly' groupId
by Brian Stansberry
Currently we have a number of different repos publishing artifacts using
the 'org.wildfly' groupId with no further namespacing.
Going forward I don't think we should allow any other new repos to do that.
It leads to administrative hassles, e.g. with setting things up in Nexus.
Best regards,
--
Brian Stansberry
Principal Architect, Red Hat JBoss EAP
WildFly Project Lead
He/Him/His
4 months, 1 week
50 or less open PRs in wildfly/wildfly queue
by Brian Stansberry
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
5 months, 1 week
