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
1 week, 2 days
[proposal] Generate "javadoc-like" documentation for feature packs
by Jeff Mesnil
Hi,
I’ve created a proposal[1] to generate a documentation archive when a feature pack is created (similar to the javadoc archive that is generated when a Java jar is built by Maven)
I’m looking for a feature team to work on this proposal.
Jean-Francois and Emmanuel already provided some PoC around this idea so I nominated you as SMEs :)
But I’d need another outside perspective to fully form the team.
This RFE does not impact the runtime so stability level is not directly applicable but I aim to do something equivalent to the quality expected by the “community” stability level.
Best regards,
Jeff
[1] https://github.com/wildfly/wildfly-proposals/pull/739
--
Jeff Mesnil
Engineer @ Red Hat
http://jmesnil.net/
4 months, 2 weeks
Deploying to JBoss Nexus
by Brian Stansberry
As many of you know, JBoss Nexus is transitioning from Nexus 2 to Nexus 3
and as part of that the processes for how we deploy artifacts to it is
changing significantly.
Please *do not deploy* anything from a project hosted in the 'wildfly' or
'wildfly-extras' GitHub orgs without discussing it with me first in a
public thread in Zulip. Thanks!
I've long had a task to write and socialize instructions around how to do
things in the new setup and I've actually made progress on that. Some of
you have seen drafts etc.
But things are still in flux and we have a number of open questions about
how things work or potential problems with the setup. So, please don't
deploy things without discussion so we can be sure whatever you are
planning will likely work.
Best regards,
--
Brian Stansberry
Architect, JBoss EAP
WildFly Project Lead
He/Him/His
6 months, 2 weeks
Developer Certificate of Origin for WildFly projects
by Brian Stansberry
One of the few requirements that Commonhaus puts on its projects is that
they use either a Developer Certificate of Origin or some kind of
Contributor License Agreement system. This is a reasonable requirement and
I believe some projects associated with WildFly are already using a DCO.
If you're impatient, skip to #3 below...
A CLA isn't really practical to administer for an organization of our
scope; a DCO is far simpler.
There are three things we need to do for a good DCO system.
1) Add a dco.txt file in each repository. Commonhaus has a jbang script
"policy-panda"[1] that checks for this when run against a GitHub org.
You may have noticed that a few days ago I spammed 88 repos in the wildfly
and wildfly-extras GH org with PRs to add this file. In case it is helpful
for other orgs, the script is at [2].
2) Add a reference to the DCO in the CONTRIBUTING.md in each repo. This is
also checked by the Commonhaus policy-panda script.
Narayana has nice text in [3] that I think is appropriate most anywhere.
(Note that the requested license/copyright header says "The Narayana
Authors". For repos in the wildfly and wildfly-extras orgs it would be "The
WildFly Authors".)
I don't think we should take immediate action on this, i.e. don't everyone
go off and start editing existing files separately. We can make a plan.
FWIW, my jbang script at [2] can also send up modification PRs, so if we
determine that big sets of repos should all use the same file it may be
helpful.
3) DCOs involve an attestation from the person submitting that code that
they agree with the DCO. This is typically done via a 'Signed-off-by' line
in the git commit message. This can be done via the -s flag (lower case) to
the git commit command.
I expect there will be lots of discussion around the logistics of adding
these signoffs! There already are in the brand new zulip thread around
this. Chatters -- please post a summary of the discussion to this thread as
many WF developers are not actively following zulip!
Note that the git commit flag for a signoff is "-s" NOT "-S" which is a
different thing that triggers gpg signing of your commit. GPG signing is
not an attestation of a DCO etc.
Rado has kindly created a WFLY issue[5] to track adding of software
enforcement of the signoff requirement. The details of that are another
topic to discuss.
[1] https://github.com/commonhaus/foundation/tree/main/templates/panda
[2] https://github.com/bstansberry/git-file-adder
[3] https://github.com/jbosstm/narayana/blob/main/CONTRIBUTING.md
[4]
https://wildfly.zulipchat.com/#narrow/channel/174184-wildfly-developers/t...
[5] https://issues.redhat.com/browse/WFLY-20791
Best regards,
--
Brian Stansberry
Architect, JBoss EAP
WildFly Project Lead
He/Him/His
6 months, 3 weeks
