[
Date Prev][
Date Next][
Thread Prev][
Thread Next][
Date Index][
Thread Index]
[
List Home]
|
Re: [jsp-dev] [External] : Re: Removing restrictions on direct commits
|
Hi all,
I just tested a direct commit with a change to the README and it was
allowed. This might be because I am still an admin for the project so
I'll wait until that karma is removed and test again.
Mark
On 05/11/2021 20:58, Mark Thomas wrote:
Hmm. This is really strange. I'm seeing some odd UI behaviour around
these settings.
With JSP the UI appears to allow PRs to be required without also
requiring at least one reviewer. Some Googling suggests there is a UI
bug here. I've tried to configure JSP to require PRs but not require
reviews. I'll need to do some testing to see if it works. Fingers
crossed...
Mark
On 05/11/2021 16:46, Mark Thomas wrote:
On 05/11/2021 16:26, Mark Thomas wrote:
I'm not convinced on the merits of always using PRs but several
people have made this comment across several projects. Given the
community desire to use PRs, I'm going to limit the changes for now
to just removing the *technical* requirement for PRs to be reviewed.
The social requirement that substantive changes must be via PR and
must allow time for community review remains.
The desire to always use PRs is something I'd like to explore but
I'll do that in another thread.
Ah.
Now I have admin access it appears that if PRs are required then so
are reviews. We can't require PRs without the review. Therefore I am
going to remove the PR requirement.
The social requirement that substantive changes must be via PR and
must allow time for community review remains.
I'll try and make my changes via PR but a few trivial fixes may end up
going directly to master.
Mark
Mark
On 04/11/2021 23:25, Ed Bratt wrote:
Just repeating the statement I made on WebSocket -- I would prefer
whatever process is adopted strongly advocates for PRs, even if the
submitter immediately turns around and then merges (and strongly
discourages direct commits). From my vantage, this provides a more
visible record about how the repository evolved. I recognize the
commit log contains all of the information but I still prefer the PR
approach.
Just my input.
Thanks,
-- Ed
On 11/4/2021 1:48 PM, Mark Thomas wrote:
As a first step, I have opened an issue to make the project lead
(me) an admin - as I should be according to the Eclipse Handbook.
With admin karma, I should then be able to make changes to the
review requirements.
Mark
On 03/11/2021 16:33, arjan tijms wrote:
Hi,
Especially for JSP I'm strongly in favour of having the
restrictions removed. We don't have an abundance of committers
including both very junior and very senior people, and there's
practically little to no in-depth reviews because of that.
If there's anything to be corrected it can be done after a commit
I'm sure.
So +1 for JSP.
Kind regards,
Arjan
On Tue, Nov 2, 2021 at 5:06 PM Mark Thomas <markt@xxxxxxxxxx
<mailto:markt@xxxxxxxxxx>> wrote:
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? Objects?
Mark
_______________________________________________
jsp-dev mailing list
jsp-dev@xxxxxxxxxxx <mailto:jsp-dev@xxxxxxxxxxx>
To unsubscribe from this list, visit
https://urldefense.com/v3/__https://www.eclipse.org/mailman/listinfo/jsp-dev__;!!ACWV5N9M2RV99hQ!YdIOBCbArHvdhYbJ7KjC5AQYftFpcg4d8iDYYNlZ2zVvm70C22nXMGVcpkzXVmg$
<https://urldefense.com/v3/__https://www.eclipse.org/mailman/listinfo/jsp-dev__;!!ACWV5N9M2RV99hQ!YdIOBCbArHvdhYbJ7KjC5AQYftFpcg4d8iDYYNlZ2zVvm70C22nXMGVcpkzXVmg$
>
_______________________________________________
jsp-dev mailing list
jsp-dev@xxxxxxxxxxx
To unsubscribe from this list, visit
https://urldefense.com/v3/__https://www.eclipse.org/mailman/listinfo/jsp-dev__;!!ACWV5N9M2RV99hQ!YdIOBCbArHvdhYbJ7KjC5AQYftFpcg4d8iDYYNlZ2zVvm70C22nXMGVcpkzXVmg$
_______________________________________________
jsp-dev mailing list
jsp-dev@xxxxxxxxxxx
To unsubscribe from this list, visit
https://urldefense.com/v3/__https://www.eclipse.org/mailman/listinfo/jsp-dev__;!!ACWV5N9M2RV99hQ!YdIOBCbArHvdhYbJ7KjC5AQYftFpcg4d8iDYYNlZ2zVvm70C22nXMGVcpkzXVmg$
_______________________________________________
jsp-dev mailing list
jsp-dev@xxxxxxxxxxx
To unsubscribe from this list, visit
https://www.eclipse.org/mailman/listinfo/jsp-dev
_______________________________________________
jsp-dev mailing list
jsp-dev@xxxxxxxxxxx
To unsubscribe from this list, visit
https://www.eclipse.org/mailman/listinfo/jsp-dev
_______________________________________________
jsp-dev mailing list
jsp-dev@xxxxxxxxxxx
To unsubscribe from this list, visit
https://www.eclipse.org/mailman/listinfo/jsp-dev
