| Re: [rest-dev] Request to Change Committer Conventions |
James,
I see your point. But in what direction points that "forward" if one vendor runs into his preferred direction (by lazy consensus) but two others stay where they are? That's not progress, but something between anarchy and chaos.
In contrast to an open source *product* (where the committers are the vendors of that product), JAX-RS is only a specification of an API to be implemented *by downstreams*. There are (at least) RESTeasy, Jersey, CXF. The API makes only sense if the majority of them actively agrees to implement it "at least eventually". Having just three vendors means: Two +1s needed to have a majority. The API makes no sense if the majority of vendors does not "at least pretend" to implement it. This is why we agreed upoin these committer rules in the early days of Jakarta REST, and it follows the democratic rules of the JCP EGs that founded JAX-RS. Lazy concensus is not democratic. It would mean that the minority wins.
If there is only a single +1, then it is easier for the user to directly go with the native API instead of JAX-RS, as that native API covers *more* features and has *higher* pace. Why should anybody go with JAX-RS if the majority of vendors does *not* implement it? Why tying to a subset of features if the sole benefit (interchangeable products) is not actually given anymore?
Hence, we need to have at least one more vendor in the boat, besides RESTeasy. This could be Jersey, if Arjan's crew is willing to invest the needed efforts (as I said, it is a shame that their previous employer Payara does not contribute actively to Jersey). So there are will then be *two* +1 provided by vendors, and another +1 is implied by e. g. the project lead (I assume that you will find a second committer that casts his vote for RESTeasy). That should work, IMHO.
Regarding bi-monthly meetings I do not see the benefit: If someone does not like to vote, he also does not like to attend.
-Markus
Sorry for the late reply. Last week got away from me 🙂
I really don't want to see the Jakarta REST spec not move forward. It's core functionality in my opinion. It's also part of the Jakarta EE Core Profile. I know that RESTEasy will at least be able to implement the specification. I can't speak for other projects though.Â
I personally like a lazy consensus, but I do think we need at minimum some kind of approval from a committer. Whether it be one or two, but it seems three right now is difficult to come by.
I do plan to send an email asking who would still like to be involved. I don't know that we can PM all the committers. I know I don't know all of their email address at least 🙂Â
We could also start having some kind of a meeting twice a month or once a month. Something like that if others are interested. Anything really to get some movement 🙂Â
James R. PerkinsSoftware DeveloperÂ
IBM
From: rest-dev <rest-dev-bounces@xxxxxxxxxxx> on behalf of Markus KARG via rest-dev <rest-dev@xxxxxxxxxxx>
Sent: Thursday, June 25, 2026 03:30
To: rest-dev@xxxxxxxxxxx <rest-dev@xxxxxxxxxxx>
Cc: Markus KARG <markus@xxxxxxxxxxxxxxx>
Subject: [EXTERNAL] Re: [rest-dev] Request to Change Committer ConventionsÂUnderstood completely. But I wonder what benefit someone has from a cross-vendor API that effectively is only supported by just one vendor anymore?
Hence stalling is exactly what should happen in such a situation IMHO, until we either agree to sunset the further development of Jakarta REST (so everybody can use latest features with vendor-specific API) *or* the other vendors wake up and get to work again.
Don't get me wrong, I really want JAX-RS to be vital and not to sunset it. But I do not see that auto-merge on lazy consensus is making it vital. It just provides a new version that with features not supported by anybody - so the consumer has no benefit of this kind of "vitality".
I think we should contact all committers by PM and clearly tell them that we expect them to be active or they get kicked out. That might trigger vitality.
-Markus
Am 25.06.2026 um 00:13 schrieb James Perkins via rest-dev:
Right, the rules are working. They are what is blocking the process and progress 🙂
I completely agree that it should not be one vendor driving the specification. The specs do better when multiple vendors or implementations are involved. You get a better API that way.
The question becomes, what do we do if they don't? In my opinion just stalling and doing nothing is not a good solution. This is where we're at now and I'm just trying to find a way to move the specification forward. I'm not trying to give any one person or company more power. I just want to unblock the process.
James R. PerkinsSoftware DeveloperÂ
IBM
From: rest-dev <rest-dev-bounces@xxxxxxxxxxx> on behalf of Markus KARG via rest-dev <rest-dev@xxxxxxxxxxx>
Sent: Wednesday, June 24, 2026 10:52
To: rest-dev@xxxxxxxxxxx <rest-dev@xxxxxxxxxxx>
Cc: Markus KARG <markus@xxxxxxxxxxxxxxx>
Subject: [EXTERNAL] Re: [rest-dev] Request to Change Committer ConventionsÂThe rules *are* working. What is not working is *the committers*. +1 for dropping inactive ones. +1 for adopting new ones if needed.
I understand that Oracle lost (in part of full) their Jersey team, which means, no more activity from them. I am willing to do more, but we need (at least) one more active committer. Then we can team up to burn down that stack.
For an international standard it makes zero sense that just IBM drives this effort, as the idea of Jakarta REST was and ever will be a *cross-vendor* standard.
So the actual problem is that those other vendors need to get active again.
-Markus
Am 24.06.2026 um 18:59 schrieb James Perkins via rest-dev:
> Also I do not like that those members that came last are the first ones to propose rule changes.
I'm sorry, but the rules aren't working. They're blocking forward progress. They not only block the Jakarta REST specification, but they also block the Jakarta EE specifications.
> There is no role called "specification lead", and according to the EF rules all committers MUST have the same weight. Projects leads explicitly do NOT have any higher powers, as the power is with the committers *by intention*.
Understandable and I'm really not trying to do that by any means. We can definitely try to re-word things in a different manor. My only concern was a potential tie and how that would be resolved. I'm definitely open to other suggestions. I'm totally okay with saying a tie is a effectively a no-go.
> What we do need is that committers must actively participate in the discussions and cast their votes in time.
I completely agree with this. The problem is, it's not happening. We've got 303 open issues and 19 PR's. None of the PR's can be merged because of our current rules. Something has to change. I'm all for getting committers to contribute more.
We have to do something to move forward. We're currently completely stuck and holding up progress. As an example my very simple component upgrade PR, https://github.com/jakartaee/rest/pull/1338, has no activity. We can't even release anything without this PR.
Again, I'm looking to getting things moving. If it moves without changing the process, great. However, as of now we're completely blocked and that is a problem.
James R. PerkinsSoftware DeveloperÂ
IBM
From:Â rest-dev <rest-dev-bounces@xxxxxxxxxxx> on behalf of Markus KARG via rest-dev <rest-dev@xxxxxxxxxxx>
Sent:Â Wednesday, June 24, 2026 09:17
To:Â rest-dev@xxxxxxxxxxx <rest-dev@xxxxxxxxxxx>
Cc:Â Markus KARG <markus@xxxxxxxxxxxxxxx>
Subject:Â [EXTERNAL] Re: [rest-dev] Request to Change Committer ConventionsÂJames,
as a long term member of this project I do not see the actual need or benefit of this change (and hereby vote -1 for your proposal).
Also I do not like that those members that came last are the first ones to propose rule changes.
There is no role called "specification lead", and according to the EF rules all committers MUST have the same weight. Projects leads explicitly do NOT have any higher powers, as the power is with the committers *by intention*.
What we do need is that committers must actively participate in the discussions and cast their votes in time.
What we also need is that committers do not vote -1 without a really good reason.
If there is no approval to a MR, this is *not* a silent agreement, but it tells us that nobody supports that change. It's as simple as that. Turning it into a silent agreement would reverse this logic and bring changes into the spec that the silent majority does *not* want.
Having said that, I reject your proposal but I am open to more actively participate if you post a top list for what you like to gain my approval. While this will not necessarily speed up the merge, it will make clear why I do not want to get it merged.
Regards
-Markus
Am 24.06.2026 um 17:23 schrieb James Perkins via rest-dev:Hello All,I'd like to make some changes to the committer conventions. This specification seems to have significantly slowed down and stopping the specification from being able to move forward.
I'd like to add a lazy consensus after the two week period. If a pull request does not have the 3 required votes, it requires 1 approval after the two weeks to be merged. This will unblock the PR queue we have now.
I'd also like to remove the -1 kills everything approach. I think we should use a majority. If there are 3 approvals and one -1, the approvals win. If there are more -1's than approvals, then the -1's win 🙂 In the event of a tie and no one is willing to change their vote, the specification leads will make the decision.Â
Please note we really need to unblock the pull request queue. Not only is this holding up this specification, it's also holding up the Jakarta EE specifications as well.
James R. PerkinsSoftware DeveloperÂ
IBM
_______________________________________________ rest-dev mailing list rest-dev@xxxxxxxxxxx To unsubscribe from this list, visit https://accounts.eclipse.org
_______________________________________________ rest-dev mailing list rest-dev@xxxxxxxxxxx To unsubscribe from this list, visit https://accounts.eclipse.org
_______________________________________________ rest-dev mailing list rest-dev@xxxxxxxxxxx To unsubscribe from this list, visit https://accounts.eclipse.org