Share Your Preference for the WildFly Community's Social Media Presence!
by Ranabir Chakraborty
Hello WildFly Community Members,
We hope this email finds you well and thriving within our vibrant WildFly
community!
As we strive to enhance and tailor our community experience to better suit
your preferences, we are excited to gather your input on our social media
presence. Your opinion matters, and we want to ensure that our community is
engaging with you in the ways that matter to you.
To facilitate this, we have created a brief poll to capture your
preferences regarding our community's social media platforms. Your insights
will help us shape our strategy and improve our communication channels.
https://forms.gle/pNZb1MdxUbF62di6A
Please take a few minutes to complete the poll, mentioned above and let us
know which social media platforms you prefer for community updates,
discussions, and events. Your participation is highly valued, and we
appreciate your contributions to making the WildFly Community an even
better place.
Thank you for being a vital part of our community!
~
*Ranabir Chakraborty*
Software Engineer
<https://red.ht/sig>
1 year
JIRAs for dependabot upgrades
by Brian Stansberry
We're starting to do a lot of component upgrades from dependabot PRs and I
wanted to talk a bit about JIRAs for those. There's been some discussion
elsewhere, but if you didn't see that or forgot....
Sometimes I or other reviewers of a dependabot PR ask that a JIRA be filed
and a comment added. Sometimes we don't ask for that. Why do we sometimes
ask, sometimes not?
Basically it's because JIRAs appear in release notes, so if the upgrade is
meaningful to end users it should have a JIRA. This means I ask for a JIRA
for production code dependencies, and perhaps for a few build things, like
Galleon tooling, that is only upgraded in the WF source for internal
reasons, but users may only learn about a new version they can use via the
WildFly release notes.
Test dependency and internal build plugin updates are not meaningful to
most users so I don't ask for a JIRA.
The other thing is we ask that the description of component upgrade JIRAs
include links to give readers (particularly reviewers) some idea about
what's come into WF. A release note link or a git diff link work. Putting
those in the JIRA description instead of the PR is better, as JIRA is the
long-term database.
But dependabot generates good changeset info in it's PRs, so if it's done
that I see no reason toe spend energy duplicating it in the JIRA. Perhaps
just say "See dependabot PR for details".
--
Brian Stansberry
WildFly Project Lead
Principal Architect, Red Hat JBoss EAP
He/Him/His
1 year
License reporting improvements
by Brian Stansberry
Kudos to Michal Petrov for the work he's been doing around license
reporting, and FYI to you all about it.
Apologies in advance if I get some of this wrong, but the gist of it is
Michal embedded the canonical information about how to describe licenses
within our licenses plugin itself.[1] This is the plugin we use to generate
the licenses.xml and licenses.html content users finds in docs/licenses in
a WildFly installation.
His work means a lot of the boilerplate we include in the source code for
our feature packs is no longer needed. See
https://github.com/wildfly/wildfly/pull/17278 for how much is no longer
needed.
https://issues.redhat.com/browse/WFLY-17755 is the JIRA that covers this.
I believe the effect of this is if a dev adds a new artifact to a feature
pack it is no longer required to add license data to our feature pack
source unless the artifact's associated pom doesn't have correct license
data. If you do need to add license info for the artifact, it's only
necessary to state the name of the license (one of the names listed in [1].)
If the "KnownLicenses" class in the plugin[1] doesn't have information
about a license, it's possible in the feature pack source to declare that
information and then reference it. See [2] as an example from the plugin
testsuite.
[1]
https://github.com/wildfly/licenses-plugin/commit/7d35dfeb161e47e6b034aa0...
[2]
https://github.com/wildfly/licenses-plugin/blob/main/src/it/insert-versio...
Thanks, Michal! This is a nice improvement that largely eliminates an
unintuitive boilerplate step when integrating new functionality.
Best regards,
Brian
1 year
