makes sense for core and it looks to be a de facto standard. but plugins and components maintained by only 1 (maybe 2) persons. we already have plenty of PRs from external contributors never reviewed... And I do not mention some PRs which take weeks to review.. I feel like adding this will: - ADDING EVEN MORE EMAILS TO THE ALREADY HUGE AMOUNT WE RECEIVE!!! (frankly it's already hard to follow anything and I already miss some ping) - delay even more moving forward (such process works for companies with people dedicated to it but we are volunteers)
core or important components that's fine but I definitely vote against moving plugins/components to RTC . On Wed, 26 Jan 2022 at 19:19, Enrico Olivelli <eolive...@gmail.com> wrote: > Il giorno mer 26 gen 2022 alle ore 07:44 Benjamin Marwell > <bmarw...@apache.org> ha scritto: > > > > Hi! > > > > Aside from typo fixes, PRs might slow down the dev speed, but greatly > > improve code quality. > > Even small PRs might have side effects you might not notice at first > glance. > > > > But then, even with typo fixes I have seen people introducing more > > fixes or unintentionally > > thought they would fix something when in fact they introduced a type. > > > > In my humble opinion, reviews BEFORE commit should be the default case. > > - review from at least 2 committers (so only one if the patch comes > from a committer) > - CI passing > > > > +1 > > Enrico > > > > > Am Di., 25. Jan. 2022 um 20:47 Uhr schrieb Slawomir Jaranowski > > <s.jaranow...@gmail.com>: > > > > > > Hi, > > > > > > On the page "Apache Maven Project Roles" [1] we have paragraph > > > about Committers with: > > > > > > The Apache Maven project uses a Commit then Review policy and has a > number > > > of conventions which should be followed. > > > > > > > > > Looks like Review then Commit policy is from svn time, so should be > > > refreshed or confirmed that is actual. > > > > > > When we want Review than Commit policy, we need some rules which allow > us > > > to effectively work if nobody is interested for feedback. > > > We also need rules / examples for direct commits, when they are > acceptable. > > > > > > Do we need different rules for Maven core, plugins, shared ... etc > > > > > > Example of rule: > > > > > > PR -> no feedback for X days -> send a mail on dev@, if still not > feedback > > > after X days after mail -> proceed alone > > > > > > [1] https://maven.apache.org/project-roles.html#committers > > > > > > -- > > > Sławomir Jaranowski > > > > --------------------------------------------------------------------- > > 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 > >
