let's step back one minute: 1. what problem are you trying to solve?
2. please take time to understand the larger bad implications I'm trying to avoid We're already struggling at maintaining full Maven scope, for the few of us who try. I seriously fear adding more constraints will make our life even harder than it is now. dist-tool is currently failing [1], but when it will work again (help welcome), you can see the last release of all our plugins, and see how many have not been released for years. When I'll see more people helping on these, I'll be ok at adding more constraints and process to the helpers. But for now, I don't need more rules or processes, I need more help on (no fun) topics people are ignoring: - data privacy impacts: https://github.com/apache/maven-site/issues/660 and linked issues to https://issues.apache.org/jira/browse/INFRA-26115 - maintenance of old plugins: choose yours please Hervé [1] https://ci-maven.apache.org/job/Maven/job/maven-box/job/maven-dist-tool/ job/master/site/ 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 > ** PMC and committers can do smaller changes , like typos, without a PR > > --- > > 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. > > ---- > > 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 :) > > 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
