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

Jan,

It is very hard not to be offended by your email. Please try and assume people are acting / going to act in good faith rather than bad faith.

Further responses in line.

On 03/11/2021 15:15, Jan Supol wrote:

<snip/>

Committing directly to the master branch allows for changes that are hard to track, as there are no PRs for them.

I disagree. Commits are as easy to follow as PRs.

They occur only when the implementation/application cannot be built against the new API.

I'm not sure what you meant by the above.

Committing directly can be reasonable, but not for introducing new features, or altering the existing ones.

Agreed. As I stated in the proposal, committers know which commits require discussion and review and which do not. Relying on social controls (expecting committers to use PRs when necessary) is better for the community than enforcing technical controls (requiring PRs + review). It significantly reduces the friction to fix minor issues and allows the (very) limited community resources to be focussed where they are needed.

It also sounds like there is a number of changes going to be made right before the release.

Correct. My experience from the last release round is that the POM in particular will require various tweaks to get everything exactly as required. I am also expecting minor issues around dates, version numbers, typos etc. needing to be fixed in the spec doc and the Javadoc. The nature of the process is that it is iterative. Requiring a PR + review for every change slows things down massively. What should take minutes often took days last time. It is primarily this that I would like to avoid.

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.

You are assuming that one of the committers would make such a last minute change. That in turn assumes a lack of trust in the committers. I see no reason for such a lack of trust.

I can see that this works quite well with the PRs, there never is a PR open more than a couple of days.

A delay of just a couple of hours for a trivial change in an iterative process that may need a handful of such changes is significant. It is this that I am trying to avoid. We have very limited committer resources. Sometimes a second committer (thanks Joakim) happens to be looking at the right email account at the right time things can move quickly but that doesn't always happen.

We should not put many new features in right now, without giving it a proper thought,

I'd go further and say we should never add new features without giving them proper thought. My current expectation is that the two currently open PRs are the only remaining potential significant changes in this release.

after not doing anything for numerous months.

I object to the "not doing anything for numerous months" statement. Progress has been being made. More would have been done if more people had stepped up to help.

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.

Agreed. This is on my TODO list. I wanted to get the remaining WebSocket PRs completed first as it is easier for me to make all the TCK changes in one PR (based on experience with EL and JSP).

Mark


Thanks,
-- 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
All,

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?

Mark
_______________________________________________
websocket-dev mailing list
websocket-dev@xxxxxxxxxxx
To unsubscribe from this list, visit https://urldefense.com/v3/__https://www.eclipse.org/mailman/listinfo/websocket-dev__;!!ACWV5N9M2RV99hQ!bFPiXYhxEWuuUJ5CzM5yxgQrAeuRub2tR1dTd9N4sUXV6R2pfH_95JEpFxUWAvOX$ <https://urldefense.com/v3/__https://www.eclipse.org/mailman/listinfo/websocket-dev__;!!ACWV5N9M2RV99hQ!bFPiXYhxEWuuUJ5CzM5yxgQrAeuRub2tR1dTd9N4sUXV6R2pfH_95JEpFxUWAvOX$>

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




Back to the top