Prepare 2.28 - rc4

[jansupol]

No description provided.

[jansupol]

Do not squash this PR

[mkarg]

According to the IP rules of the EF parts of this commit are my IP (see #4016), so for legal reasons (and to be fair to me) there MUST be a commit with my user ID instead of yours. Hence I would like to kindly ask you to first adopt my PR and then rebase your PR ontop, this will fix the IP issue.

[jansupol]

The term Intellectual Property (IP) refers to any sort of creative work, be it literature, art, or software. In the realm of open source software, artifacts like source code, documentation, and images are considered intellectual property. Unless otherwise stated, intellectual property is the property of its creator, who may grant permission for others to use that intellectual property by providing a license.

@mkarg You need to explain this. You have created a single symbol change commit that broke the build. You pushed the PR, you left the build fix on us, you did not try to fix it. We have spent our time (significantly more time than one symbol change) in finding the correct fix. And you want to claim that all to be your IP and you say we are not fair to you?

We gladly helped you the last time with the failing tests, it took us quite some time to find the OSGi fix. But simply updating versions without addressing issues caused by the new versions and breaking builds is not the way how anyone should do the PRs.

[mkarg]

@jansupol Seasons greetings to you as well and nice to see you, and I am happy to explain this! This is a complete misunderstanding! I do not want to claim the IP for the complete change. I only claim the IP for that small single commit I made (despite the fact how small it is, and independent whether it was a non-self-contained or non-working PR, as all of this plays no role for the question of IP). Certainly all the rest of the PR is your IP. I have amended by PR without your fix days ago so you can simply rebase your PR branch on my PR (no other efforts needed) and the legal stuff is 100% correctly done within the work of just one minute (less time than writing your recent comment; less time than reading my answer). That would be fair. Not mentioning me at all is defintively unfair, as you could simply have added a Also-By: line whithin five seconds! BTW, I did try to fix it, but as I have no clue of OSGi and Felix I simply left the rest to you as I expected that your team (as the originator of the Felix use) simply knows the missing brick rather instantly - I did not expect that you need to spend any measurable time in finding the source of the issue. Also I did not break your build, I broke just mine, which is pretty acceptable for a work in progress. Regarding "who helped whom", please note that the PRs (this one and the last one) regarding JAX-RS upgrades were just intended as starting points (or reminders) as a benefit for your team to (a) be notified about the recent version I published on Maven Central (so you do not need to manually lookup it somewhere) and (b) you can simply push the missing commits ontop without starting from scratch. If neither (a) nor (b) is wanted just tell me so I will not further provided PRs for recent JAX-RS updates in the future. Regarding your last comment I cannot see how we can work together; it implies that no shared works are wanted by you, so the only solutions would be (1) only full time Jersey developers that know everything about all aspects of the product shall open PRs or (2) I shall mark incomplete PRs with WIP:?

[jansupol]

@mkarg Happy new year to you too. I hoped the new year won't bind us with a new set of rules, especially about trivial PRs. Really, we are glad for PRs, even for the ones that just upgrade a version of a dependency. But if the PR does not build, and does not contain any change that solves any issue, it just upgrades a version, I feel free to ignore it.

In general, PRs like this bring only additional complexity for others whoever wants to provide fixes, while the added value provided by the original trivial commit is arguably none. All that would really looks like the reason is not that the committer wants to help, it looks more like the reason is to have his own name in the log. I do not feel like we should support that. I do not suspect it's your case, I am sure you are capable of providing lot's of great PRs, but in general, we really should not support these trivial PRs.

I do not imply PRs should be 100% working. As soon as they contain any added value, they originator should not be omitted and I am happy to spend some time with helping it. Having WIP: is a good idea, but it sounds more like the original committer is still working on it and just accepts comments. If the committer is stuck and needs help, it's better to add a comment. But please, let it be a meaningful PR.

[mkarg]

@jansupol Agreed (BTW, I do not see any new rules). I really just wanted to post a reminder with this PR as I noticed you didn't pick up the new version for some time and thought it is clear what I intend to do. Looking at the Java SE Bootstrap PR and my role in JAX-RS, I think we agree that I am definitively not the one that just "wants to read his name in some log". Looking at the many PRs of your team that doesn't contain any comments at all but just a sign-off line I thought it is OK to trigger ideas this way. Anyways, I think all is said, and I will add a comment clarifying why a buggy PR is sent next time (as I did in the past but just not with this single one). Sorry for the trouble.

[jansupol]

Running addLegalInfo profile is rather slow. It extends build time from ~20 minutes to more than an hour. While having this in a profile used just once per release could be ok, it would be better to use a different plugin that does not slow the build that drastically. Experiments show the build-helper-maven-plugin could be replaced.

[jansupol]

superseded by #4031