Hi Cédric,
Please set aside some time to review the following PR:
https://github.com/apache/groovy/pull/860
Cheers,
Daniel.Sun
-
Apache Groovy committer
Blog: http://blog.sunlan.me
Twitter: @daniel_sun
--
Sent from: http://groovy.329449.n5.nabble.com/Groovy-Dev-f372993.html
> *From:* Daniel.Sun
> *Sent:* Sunday, January 27, 2019 3:46 PM
> *To:* d...@groovy.incubator.apache.org
> *Subject:* Re: About the lazy consensus on Pull Requests
>
> Let's have a look at some examples to clarify the "big changes":
>
> 1) Removi
g the indy jars and so they would likely experience some difference in
compilation or execution, even though all the same class files are delivered in
the jars.
From: Daniel.Sun
Sent: Sunday, January 27, 2019 3:46 PM
To: d...@groovy.incubator.apache.org
Subje
Let's have a look at some examples to clarify the "big changes":
1) Removing unnecessary boxing and unboxing modifies a lot of files, it is a
big change but it is just a refactoring, so I think it can apply the lazy
consensus strategy.
2) Supporting switch expression of Java 12 will impact groovy
It's less about time to review than it is about being available, thinking
about the change and accepting it. Especially you mention "big changes". If
you can qualify what you mean by that, we can discuss. Otherwise to me it
should be a no-go: reviews should be done. And, if you're blocked, sending
Luckily according to current HR of groovy core team, it's hard to archive a
big change which need more than 72 hours to review...
-
Apache Groovy committer
Blog: http://blog.sunlan.me
Twitter: @daniel_sun
--
Sent from: http://groovy.329449.n5.nabble.com/Groovy-Dev-f372993.html
I agree that no "big change" should be merged without review. 72h may sound
a lot, but it's not.
Le dim. 27 janv. 2019 à 22:01, Daniel.Sun a écrit :
> I agree with you on most of your opinions, but some of them are a bit ideal
> for an open source project such as Apache Groovy IMHO. I feel that
I agree with you on most of your opinions, but some of them are a bit ideal
for an open source project such as Apache Groovy IMHO. I feel that it is
really hard to please all...
P.S. One of my big projects has already used groovy 3.0.0-alpha-4, so far so
good.
Cheers,
Daniel.Sun
-
Apache
I don't believe there is such a thing as "lazy consensus". IMO nobody should
be merging their own pull requests. And 72 hours is not enough time for
feedback, especially for a major change. It is quite easy for someone to be
away from work email for 72 hours with just 1 day vacation/sick time
> Yes, it is always wise to notify the mailing list about upcoming major
changes. While not every change will bring about discussion, in those cases
where there is discussion, it can reduce the need to have to rework PRs. So
it is often both courteous and efficient at the same time.
Agreed.
Cheer
Yes, it is always wise to notify the mailing list about upcoming major
changes. While not every change will bring about discussion, in those cases
where there is discussion, it can reduce the need to have to rework PRs. So
it is often both courteous and efficient at the same time.
On Sun, Jan 27,
No objection from me, assuming that major changes are brought up on the mailing
list first.
Remko
> On Jan 27, 2019, at 3:09, Daniel.Sun wrote:
>
> Hi all,
>
> In order to make all major changes reviewed, I create PRs for each
> major change. And the PRs will be merged in 72 hours by
Hi all,
In order to make all major changes reviewed, I create PRs for each
major change. And the PRs will be merged in 72 hours by default if no one
rejects the PRs. So I am not going to add any note like "merged in 72 hours
if no one rejects" for each JIRA ticket and PR.
If anyone ob
13 matches
Mail list logo
