Add a codeowners file

[jamezp]

This might not make sense for this project. However, it's something we should consider given there is currently no real owner of this project. https://docs.github.com/en/repositories/managing-your-repositorys-settings-and-features/customizing-your-repository/about-code-owners

[rhusar]

Step 1: let's find an owner of this "project"!

[jamezp]

1.2.3; not it haha

This one might actually need at least a couple leads. I say that because while say one upgrade of a component might work for one project, that doesn't mean it will work for another because of some random bug.

[rhusar]

1.2.3; not it haha

This one might actually need at least a couple leads. I say that because while say one upgrade of a component might work for one project, that doesn't mean it will work for another because of some random bug.

I think the way to handle this is fairly straightforward and outlined in #113 (comment) - TLDR: this needs individual CI steps that test the changes against projects consuming jboss-parent at the snapshot version with the proposed change.

[jamezp]

Something like WildFly can't run on GitHub actions though. Which brings the question; which projects? I do think it's a good idea to add testing on projects though.

Another thing to consider is knowing whether or not the projects are explicitly overriding versions. For example in RESTEasy I know we override the version.surefire.plugin version.

Again, not arguing we don't add some projects to CI here, just kind of brain dumping some thoughts :)

[jorsol]

Just to give my two cents here:

• This project works like an umbrella parent pom for many projects, if an upgrade of one component (or many components) works for one project but not for another project due to some random bug or more likely due to a misconfiguration of that project, it doesn't mean that there should be stuck on older versions of components/plugins just for that reason, maybe with just some small configuration changes that failing project could work too.

  Just as an example, let's assume that one plugin is removed from the parent-pom, it's superseded by another, or simply is no longer needed which could break some consumer projects, yet it should be up to the consumer project to manage that situation, it's should be noted in the changelog of the released version all the updates/changes made so that consumers could take note and act accordingly.

  If there is indeed a random bug that makes a project fail, it should be reported back to upstream allowing to fix that bug globally, then a new parent-pom could be made available with the fix for all projects too. This is the release early, release often of open source.

• Using CI is a nice idea and could probably be done by adding a side project with the maven-invoker-plugin, the thing is, it's impossible to test against projects like wildfly, resteasy, quarkus, et all, without a big effort just to ensure "compatibility". My recommendation is to add simple and reproducible projects using the features present in the parent-pom, like the Multi-Release jar, overwriting the compiler-plugin release/source/target, basic testing of checkstyle, pmd, spotbugs, etc. It's not necessary to duplicate what consumer projects are doing, just making use of what the parent-pom provides should be enough.

[dmlloyd]

We have CI now, and apart from that I don't think a CODEOWNERS would give us much since the whole project is only a couple of files. The communication channel for this project is to file an issue or a PR, and CI should take care of the rest. We can add more CI projects over time.

Shall I close this issue?

[rhusar]

We have CI now, and apart from that I don't think a CODEOWNERS would give us much since the whole project is only a couple of files. The communication channel for this project is to file an issue or a PR, and CI should take care of the rest. We can add more CI projects over time.

Shall I close this issue?

@dmlloyd The general idea was to use the CODEOWNERS mechanism as a way to let the contributors know who is responsible and/or willing to review and merge the PRs. The CI definitely helps with the review aspect but not exactly with merge aspect. Anyway, this problem can be solved be either having somebody actively reviewing the PR queue or by having a list of mergers to ping. Also, the downside of CODEOWNERS is possible noise if it were to ping a lot of people.

[dmlloyd]

Well, I'm open to a concrete proposal (i.e. a pull request). I guess the code owners are just me, and maybe @bstansberry assuming he's not running at maximum speed in the opposite direction! (Any other volunteers??) But either a PR should be proposed or we should close the issue.

[bstansberry]

I'm not running away, and +1 to a PR.