>> 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.
Knowing that the number is very low, I totally understand this.
For me personally as a new one, written policies (how strict or loose
they are, but mentioned) help to getting started.
>> and literally security"? really, I suggested that?
No you suggested to discuss this on ML :)
My summary was over all comments (Elliotte mentioned the security topic,
that's why I put it in the list)
Matthias
Am 07.02.2025 um 07:08 schrieb Hervé Boutemy:
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
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
For additional commands, e-mail: dev-h...@maven.apache.org
