Le jeudi 6 février 2025, 20:51:09 CET Matthias Bünger a écrit : > Hi all, > I would like to bring the (as of my understanding) not yet finished > discussion about the commit/review policy with Github from a _merged_ GH > PR [1] to the mailing list, as suggest by Hervé: > > As a short summuary: > * In times of SVN there was "Commit Then Review" (CTR) policy > * Since Github, this has changed to > ** We encourage PR for better release notes and literally security "and literally security"? really, I suggested that?
> ** PMC and committers can do smaller changes , like typos, without a PR no notion of PMC on commits: just committers (who technically can commit) > > --- > > I personally like PR for all changes (combined with branch protection), > but I totally understand the argument that in general experienced > project members (of any OSS) are responsible enough to create PR for > "real changes", but might want to quick fix typos without one. > However we all know that PRs are not only for checking about > correctness, but also about if code is easy to understand (like > meaningful variable names) and knowlegde transfer between people. Ofc > these points to not apply on "I quickly fix a typo"-commits. > > Hervé suggested to discuss this topic and upate the current policy to > the changes brought by the switch from SVN to Github. He also suggested > to have a more relaxed one in the start and be more strict in the > future. So fow now, I'll start with the following propal: > > ---- > * All contributer and committer must always open a PR regarless of the > change they want to provide > * PMC members are allowed to do small changes, not noteworthy in release > notes (like typos) without a PR. All other changes need to be reviewed > through a PR before merge. > * There is no main branch protection yet, but might be introduced at any > point in the future. > > ---- going back to existing policy before changing means not forcing PRs: full stop. No reason to differentiate committers and PMC members: PMC is not about technical work. As a new joiner, if you felt that PMC role gave some voice here, I'm interested to hear about it see https://maven.apache.org/project-roles.html#Project_Management_Committee for (lengthy) description For contributors, PR is de-facto the only way to contribute (as were patches in the svn time) > > I would also add the point of "Whats the numbers of approvals to merge a > PR?" to this discussion. As mentioned on Slack I'm not sure if we > need/want something like this, but I think it fits well into this discussion > > I saw PRs merged more or less instantly after one approval by a PMC, > others stay open even with multiple PMC approvals. > On release votes there is a minimum PMC quora rule to be allowed to > release, but I‘m unaware of how it‘s decided that (proposed) changes > should be implemented / PRs get accepted. > I'm also maintainer in another small open source project (JUnit Pioneer) > we decided that at least two maintainers have to approve a PR, before > merge. If the PR is opened by a maintainer, this counts as one approval. > For Maven, if we want somithing similar that could be like a) 2 > Committers + 1 PMC or b) 2 PMC have to approve. > > > Let's have a constructive discussion here on the ML. > > @Hervè I'm open to update site when we have agreed on any result :) it seems I'm forced to ask for simply reverting the initial PR that changed the policy without real discussion (just managed to have an approval overlooked by others, on something that definitively is not just a technical code change): anything smarter than basic revert goes immediately to people wanting to force PRs on others, instead of staying soft. Me trying to be soft and trying to listen looks like a lost hope, sadly. so I say -1 on https://github.com/apache/maven-site/pull/569 (as olamy started to propose, but I was hoping to avoid the feeling of such a basic revert) which means "veto, please revert" in the "Commit Then Review" convention that has been active for more than 20 years with great success (and that this PR tried to change) Regards, Hervé > > Greeting > Matthias > > [1] https://github.com/apache/maven-site/pull/569 > > --------------------------------------------------------------------- > To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org > For additional commands, e-mail: dev-h...@maven.apache.org --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org
