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
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
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
> 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.
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
