Skip to main content
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [List Home]
Re: [rest-dev] Request to Change Committer Conventions
  • From: James Perkins <jperkins@xxxxxxx>
  • Date: Wed, 24 Jun 2026 16:59:44 +0000
  • Accept-language: en-US
  • Arc-authentication-results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=ibm.com; dmarc=pass action=none header.from=ibm.com; dkim=pass header.d=ibm.com; arc=none
  • Arc-message-signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector10001; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1; bh=ljSd+HF5t/tFX2cP8IIfo4QkEbeZU5Lyv+Awdg/wihE=; b=pVF62VtxWE1qOMe/TZyUB8mcgh/Tu47GENMK7jeVknPQYmcWHCEgmOqqVXGPSE9MdiTSIsKfsZ2Cfuj9y6ByQ41Qq8bwHXkLGYk/JP9Wj7bwyBZ1gfBxKqDW+RF21OaAsp4rpoKJUOSxRpy//trXZnLd/BhhtcQS37r0sCc0EfBg3JQd8cM6X2+CPW4BGFVzkupUIp6vuUDdUETspZkf5sobg8soClIFamTanQKwVgV8iQgYkx4PzfC/KcyHY7xhvPXX9VTjI9o+OhpLkQ5JkZ74AGRIPRt2RvAv8A4prD0asy69kq3M01mpR61L5NcF8c4bG6DhBxb6mDNazgjWbg==
  • Arc-seal: i=1; a=rsa-sha256; s=arcselector10001; d=microsoft.com; cv=none; b=VP4ynQ4rPPp1nIEg/d9GfOAAneNlKNmQKpDndVXbNlhxSBLX1NrvikS7824GLBg9aapfUug8z2+FfhOc6jV8RgrTac7r9a+J4E8ZHWShMAJABXDCXczah7sVIViiminUWdoA6yUKvdRdA/Ln3rlt1FJKtnQMeDvqFqHjMjKqE4KYFc8ZG9xJqEyjWwC/FywPQOxky1BNzRkWJ3oN1UmsydAWLC1i7Yov7QPzQ/MdNiQQrIkwNG5bksamVpHxCSxPJrwOOsf0tpPDvFRuRyPWJ+keMnGtHba/J5LSTqie9ztY7rYFZB2J0m8jivx4Z6XEIcdemxK25o1zmZCS1waD1g==
  • Delivered-to: rest-dev@xxxxxxxxxxx
  • List-archive: <https://www.eclipse.org/mailman/private/rest-dev/>
  • List-help: <mailto:rest-dev-request@eclipse.org?subject=help>
  • List-subscribe: <https://www.eclipse.org/mailman/listinfo/rest-dev>, <mailto:rest-dev-request@eclipse.org?subject=subscribe>
  • List-unsubscribe: <https://www.eclipse.org/mailman/options/rest-dev>, <mailto:rest-dev-request@eclipse.org?subject=unsubscribe>
  • Msip_labels:
  • Thread-index: AQHdA+Rcj5B26HzrX0eQxXQ3xvADdrZN4jKAgAAGzA4=
  • Thread-topic: [EXTERNAL] Re: [rest-dev] Request to Change Committer Conventions
> 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

Back to the top