Skip to main content

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [List Home]
Re: [websocket-dev] [External] : Removing restrictions on direct commits
  • From: Jan Supol <jan.supol@xxxxxxxxxx>
  • Date: Wed, 3 Nov 2021 15:15:36 +0000
  • Accept-language: en-US
  • Arc-authentication-results: i=1; 1; spf=pass; dmarc=pass action=none; dkim=pass; arc=none
  • Arc-message-signature: i=1; a=rsa-sha256; c=relaxed/relaxed;; s=arcselector9901; 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=V3LWoT57iMIPbUAezvA/3SF/gVRgvZojQgtlO3dVYxI=; b=WfT34E2Qno5X9GeP94War6vgo8OinSz0yZE2W5ahgzjNzg9y770CbFD1qx2JyjWrM0z3s/NhQuZn93dJIRFcg5T6mZRV5GMhe8xON1tSOVL0MLH1FHAkYg/L8nRoKJZyn7SaHAbtf5EcV0qz23yVjMAaf3tWR02gLb2GCGrb6aHpH9j6iVCzFd79YDegT4r9iU5r/XCtjUDEhEpgGoNEYOj7eocYwqaoi2UueRe3HdjzcKyPgII+6WGXP6efsECkWZBi/W44XTdQBlarze1EgW4XmGMthpBMV15frkgBqNGu2hBtf+qgNbjkEQol9xx8Ra7ef36PqYo2eh63jt++Ww==
  • Arc-seal: i=1; a=rsa-sha256; s=arcselector9901;; cv=none; b=TbrrLOcIPwMmcSRC6Oh5kkk0Z9P/A6UtIqccHyJTNgBhSNaBBAKH3XFKGbE6BocmT7sSOUunARxR+kwiUi5PFEmiUhPGFQqyNAGgn6629nALC1bVwTibx4zI4F+kNt6Xyj5kZzbJSG5IjBK1kjIHtL4aoqaNhTEq5h2t56vCVYoZZSh+Zi2Afiys+dkgOWV921wT5P/FfPbxavYDu5LrRQVg8A/opnkuoFG0aJ/UrqXzdIkrqyMCZJjuF2ghAPCjcMxlgF68ZyK1BFEX8csQWZHzebG466QnN7uhY88WILHrQ01fog6aLp/7VCSbwZAlf3Qls1VUu0eA0L2hBwHbTA==
  • Delivered-to: websocket-dev@xxxxxxxxxxx
  • List-archive: <>
  • List-help: <>
  • List-subscribe: <>, <>
  • List-unsubscribe: <>, <>
  • Suggested_attachment_session_id: 166429b3-934b-695a-264e-e1889b6d2897
  • Thread-index: AQHX0AbfEVEQw9ZeCEy3Hb5o4iGjCqvx5rXr
  • Thread-topic: [External] : [websocket-dev] Removing restrictions on direct commits

To me, this sounds evil.

Committing directly to the master branch allows for changes that are hard to track, as there are no PRs for them. They occur only when the implementation/application cannot be built against the new API. Committing directly can be reasonable, but not for introducing new features, or altering the existing ones.

It also sounds like there is a number of changes going to be made right before the release. I am not a fan of big changes that can surprise both the vendors and customers this short before the release, this is why the review should always be made. I can see that this works quite well with the PRs, there never is a PR open more than a couple of days. We should not put many new features in right now, without giving it a proper thought, after not doing anything for numerous months.

I would also like to note that every API/Spec change should go in along with the TCK test, which is not the case with the last changes. 

-- Jan

From: websocket-dev <websocket-dev-bounces@xxxxxxxxxxx> on behalf of Mark Thomas <markt@xxxxxxxxxx>
Sent: Tuesday, November 2, 2021 5:29 PM
To: websocket developer discussions <websocket-dev@xxxxxxxxxxx>
Subject: [External] : [websocket-dev] Removing restrictions on direct commits

In approx 24 hours time I intend to request that the branch restrictions
that prevent committers committing directly to the master branch and
those that require every PR to be reviewed before merge are removed.

My reasoning is as follows:
- I have seen the benefits of these restrictions not being present in EL
- I'm expecting a number of non-substantive changes will be required to
   successfully complete the release process and PR + review for all of
   them will significantly slow us down
- Committers are perfectly capable of determining which changes need a
   PR and review and which can be made directly - and if they get it
   wrong changes can easily be reverted

I was intending to propose this change after the Jakarta 10 release but
on reflection, I think the sooner, the better.

Thoughts? Comments? Objections?

websocket-dev mailing list
To unsubscribe from this list, visit;!!ACWV5N9M2RV99hQ!bFPiXYhxEWuuUJ5CzM5yxgQrAeuRub2tR1dTd9N4sUXV6R2pfH_95JEpFxUWAvOX$

Back to the top