Agree, 3 days is nothing.
Am 2022-02-03 um 12:23 schrieb Xeno Amess:
3 days?
according to my experience, usually you need 30 - 180 days.
Tibor Digana 于2022年1月28日周五 06:40写道：
It's nice to write some rules but still the developers are not machines.
You can, for instance, get some vote for
Hi Xeno,
The openjdk would close such a PR which has no attention. I am keeping it
open if it is not necessary to close it, and I am doing it because I
respect the time the contributor has spent on it and I want to give him a
chance to continue or open a discussion. Yesterday I closed one old PR
things in openjdk is if a pr cannot gain interest from any already-in
members, although it might be a great pr, it is automatically-closed.
> There cannot be a rule "No review" -> "wait 3 days" -> "accept" because
this is the thing everybody would utilize to involve a trojan horse.
yep, at least
Slawomir, we have a fundamental problem.
You want to accept PR. But I say that the purpose of PR is not to accept it
because the ASFshould be always critical and therefore I think the rules
cannot be written in terms "When to accept the PR".
There should be rules "When not to accept the PR"
Hi,
Example value as 3 days or other values are to discuss and can be an agreed
value. Now such values are not important ... it will be the last item to
confirm.
I only want to show how the process can look.
Currently we only have sentence that we use "Commit then Review" policy
without more
Yes, reviewing prs is time consuming, though usually worth it.
3 days does not seem enough for normal pr reviews I think.
If a maintainer disagrees with this and they do think they can review every
prs inside the 3 days limit, then I will be glad to show him why he can't,
just tell me what repos
IMHO the reactions against PRs should be technically critical.
IMHO the PRs from contributors should not be accepted unless there are
objections or pending objections.
Example, would you move your hand up and accept long commit in a PR even if
you do not see the following statements?
*if ( cha[]
3 days?
according to my experience, usually you need 30 - 180 days.
Tibor Digana 于2022年1月28日周五 06:40写道：
> It's nice to write some rules but still the developers are not machines.
> You can, for instance, get some vote for totally crazy things like removing
> public method in a library which is
It's nice to write some rules but still the developers are not machines.
You can, for instance, get some vote for totally crazy things like removing
public method in a library which is widely used in ASF or in the world.
Yes, your right against the rules but was this according to the best
Am 2022-01-26 um 22:00 schrieb Slawomir Jaranowski:
Hi,
What do you think ...
Maven Core and important components (list needed)
- RTC obligatory, approve from X committers, no request changes
Good.
Common rules:
- build and tests always pass or are under control
- after each commit
Hi,
What do you think ...
Maven Core and important components (list needed)
- RTC obligatory, approve from X committers, no request changes
Common rules:
- build and tests always pass or are under control
- after each commit project is ready to next release
- as maintainer add page
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:
-
Howdy,
In your example rule, between 1st and 2nd step I'd insert some "invite
interested parties" step, that is either request review using GH UI, or
ping party via mail... As currently our incoming email amount is huge,
it is way too easy to miss some.
Also, when asked for review, the one asked
Il giorno mer 26 gen 2022 alle ore 07:44 Benjamin Marwell
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
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
Hi,
I'm happy with the current rule/process CTR and not sure we want to receive
more notification emails... when someone creates a PR to fix a typo in some
documentation/javadoc or some very easy changes.
We have enough experience to create a PR when really necessary.
On Wed, 26 Jan 2022 at
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
17 matches
Mail list logo
