Hi,
The vote has passed with the following result:
+1: Michael Osipov, Karl Heinz Marbaise, Hervé Boutemy
PMC quorum: reached
I will promote the artifacts to the central repo, the source release ZIP
file
and add this release the board report.
Hi,
The vote has passed with the following result:
+1: Michael Osipov, Hervé Boutemy, Karl Heinz Marbaise
PMC quorum: reached
I will promote the artifacts to the central repo, the source release ZIP
file
and add this release the board report.
Am 2022-02-01 um 22:02 schrieb Michael Osipov:
Hi,
We solved 4 issues:
https://issues.apache.org/jira/projects/MSHARED/versions/12331438
There are still a couple of issues left in JIRA:
https://issues.apache.org/jira/issues/?jql=project%20%3D%20MSHARED%20AND%20resolution%20%3D%20Unresolved%20AN
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 total
Am 2022-02-01 um 21:40 schrieb Michael Osipov:
Hi,
We solved 8 issues:
https://issues.apache.org/jira/secure/ReleaseNote.jspa?projectId=12317821&version=12351291
There are still a couple of issues left in JIRA:
https://issues.apache.org/jira/projects/MPIR/issues
Staging repo:
https://reposi
Guillaume,
can we leave it like this for M1 and I will slate your PR for M2?
M
Am 2022-02-01 um 22:54 schrieb Guillaume Nodet:
-1
Would it be possible to at least get rid of direct (and transitive if
possible) dependencies on maven 2.x artifacts ? Especially those that do
not exist anymore...
Am 2022-02-01 um 21:40 schrieb Michael Osipov:
Hi,
We solved 6 issues:
https://issues.apache.org/jira/secure/ReleaseNote.jspa?projectId=12317320&version=12351216
There are still a couple of issues left in JIRA:
https://issues.apache.org/jira/issues/?jql=project%20%3D%2012317320%20AND%20statu
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
be
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" because
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 deta
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 he
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[] ==
13 matches
Mail list logo
