Skip to main content
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [List Home]
Re: [ee4j-pmc] [rest-dev] Request to Change Committer Conventions
Thank you, Wayne, for reviewing the REST specification project and providing your view.

I'm not a committer on this project but my company OmniFish highly desires that the project actively evolves, following all the standard rules. I believe that the problem is not the rules themselves but the lack of activity and transparency in project communication and processes. After Oracle employees stopped participating in this project, IBM is a single company that can and is willing to dedicate engineers to regularly work on it. There are some other committers from the community or smaller companies like OmniFish that are willing to participate irregularly. We might be able to find more committers that can dedicate some of their time in the future. 

Markus Karg already expressed his willingness to prioritize reviews of some PRs if asked. Arjan Tijms, my colleague in OmniFish, is in the same position. I'm also willing to contribute and later become a committer if I manage to pass the nomination requirements. I'm not active in this project but I have a history of discussing several new APIs in JAX-RS for Java EE 8 and I also contribute to Jersey.

At this stage, I think that the rules are OK and they work in other specifications, even the less active ones. The spec team should focus on
  • Contacting existing committers and find out who's willing to contribute or at least review PRs
  • Triaging existing PRs and prioritize them, so that committers with limited time can review the most important ones first
  • If committers don't follow the communication on Github, consider using other channels. This mailing list looks like a good channel to escalate any priority PRs or seek attention of other committers
  • Ask the community for contributions and try to bring enough contributors so that some of them can earn the committer status in the future  
  • Mark some simple PRs or issues with the good-firtst-issue label or something similar to help new contributors learn how to contribute simple stuff first
All the best,
Ondro Mihalyi

Director, Jakarta EE expert
OmniFish - Modern Jakarta EE Runtimes | www.omnifish.ee

On Wed, 1 Jul 2026 at 06:46, Wayne Beaton via ee4j-pmc <ee4j-pmc@xxxxxxxxxxx> wrote:
Hey Jakarta RESTful Web Services team.

/cc EE4J PMC

The EMO rejects the notion that the opinions of long term committers are any more important than those of newer members. A committer is a committer. Committers are folks who have gained the project team's trust and have been voted in (or have otherwise earned their maintainer responsibilities). Established maintainers should value the opinions and enthusiasm of new maintainers.

I spent time reviewing project content and could find no documentation of the rules that you describe. It is, of course, common for open source project teams to have unwritten rules, but it makes it difficult for your community to understand how the project operates when the rules are not explicit and easy to find. Your project-specific contribution rules should be described in the CONTRIBUTING file.

I also don't see where votes are being recorded. I can find no meeting minutes, and, AFAICT, issues have been left open for weeks and months without resolution or any indication to contributors about why they're being held up. Can somebody provide pointers to where these decisions are being made and tracked?

AFAICT, you have a rule requiring two positive reviews by committers before a pull request can be merged. AFAICT, the project team has exactly one committer who has made actual content contributions in the past year (other committers have shown very limited engagement in issues and pull requests). That is, AFAICT, in its current state, the project team cannot possibly implement its rules.

AFAICT, the project team is squandering opportunities to court contributors and convert them into committers; putting your actions at odds with the goal of growing the team. You have numerous first-time contributors showing up and being ignored.

Please correct anything that I have gotten wrong.

By my observation, the project appears dysfunctional and is unlikely to progress or attract new maintainers in its current state. Your rules aren't working.

Please find a practical path toward progress. 

he Eclipse Foundation Development Process burdens the PMC and EMO with the responsibility and authority to mitigate issues that arise when committers fail to perform the required behaviors or engage in practices that risk harm to the project. We wield this authority infrequently and reluctantly. I would very much rather not have to use this authority.

To manage expectations, I will be away until July 6 and unable to respond during that time. The EE4J PMC will be able to respond to your concerns.

I look forward to a positive outcome,

Wayne

 
From: Markus KARG via rest-dev <rest-dev@xxxxxxxxxxx>
Date: Thu, Jun 25, 2026 at 6:30 AM
Subject: Re: [rest-dev] Request to Change Committer Conventions
To: <rest-dev@xxxxxxxxxxx>
Cc: Markus KARG <markus@xxxxxxxxxxxxxxx>


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. Perkins
Software 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. 

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. Perkins
Software 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

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. Perkins
Software 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
_______________________________________________
rest-dev mailing list
rest-dev@xxxxxxxxxxx
To unsubscribe from this list, visit https://accounts.eclipse.org


--

Tanja Obradović

Java Programs, Sr. Manager | Eclipse Foundation

Twitter:@TanjaEclipse

Eclipse Foundation: The Community for Open Collaboration and Innovation




--

Wayne Beaton (he/him)

Head of Open Source Projects | Eclipse Foundation

_______________________________________________
ee4j-pmc mailing list
ee4j-pmc@xxxxxxxxxxx
To unsubscribe from this list, visit https://www.eclipse.org/mailman/listinfo/ee4j-pmc

Back to the top