You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@groovy.apache.org by "Daniel.Sun" <su...@apache.org> on 2019/01/26 18:09:05 UTC
About the lazy consensus on Pull Requests
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 objects to the lazy consensus strategy, pls let me know.
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
Re: About the lazy consensus on Pull Requests
Posted by "Daniel.Sun" <su...@apache.org>.
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
Re: About the lazy consensus on Pull Requests
Posted by Cédric Champeau <ce...@gmail.com>.
Ok so I think we all agree (you, me and Eric): to me a "big" change is
directly related to how it impacts users. Internal refactorings that touch
a lot of files are not necessarily "big" in terms of impact.
Le lun. 28 janv. 2019 à 17:48, Milles, Eric (TR Tech, Content & Ops) <
eric.milles@thomsonreuters.com> a écrit :
> I think "big" refers to impact to users of the language, not number of
> files/lines touched. Let's say you change copyright notices; that will
> affect a lot of files but not a lot of users. Changes like altering the
> jars structure, how the static type checker works, new language syntax,
> making compile static on by default are examples of "big changes" that will
> impact users.
>
>
> Another example, let's say I want to make "indy" the new default and get
> rid of the separate classified jars. This is a big change since many, many
> users are not using 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 <su...@apache.org>
> *Sent:* Sunday, January 27, 2019 3:46 PM
> *To:* dev@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) 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 users, it is
> a
> big change and can not apply the lazy consensus strategy.
>
> Agree with me?
>
> Cheers,
> Daniel.Sun
>
>
>
>
>
>
> -----
> Apache Groovy committer
> Blog:
> https://urldefense.proofpoint.com/v2/url?u=http-3A__blog.sunlan.me&d=DwICAg&c=4ZIZThykDLcoWk-GVjSLmy8-1Cr1I4FWIvbLFebwKgY&r=tPJuIuL_GkTEazjQW7vvl7mNWVGXn3yJD5LGBHYYHww&m=_b29NYtGgrijCwV2rG6I3Bg70IXBiuUWMMCfYpexP9c&s=2DLn8nmHOUU2_Qlx-jzlHxSsQ4dfNUxCljdyis8yXTY&e=
>
> Twitter: @daniel_sun
>
> --
> Sent from:
> https://urldefense.proofpoint.com/v2/url?u=http-3A__groovy.329449.n5.nabble.com_Groovy-2DDev-2Df372993.html&d=DwICAg&c=4ZIZThykDLcoWk-GVjSLmy8-1Cr1I4FWIvbLFebwKgY&r=tPJuIuL_GkTEazjQW7vvl7mNWVGXn3yJD5LGBHYYHww&m=_b29NYtGgrijCwV2rG6I3Bg70IXBiuUWMMCfYpexP9c&s=w8m2klmc3e4i2w9gi8m8TjmQs1RxesdubEgIjd7_8vE&e=
>
Re: About the lazy consensus on Pull Requests
Posted by "Milles, Eric (TR Tech, Content & Ops)" <er...@thomsonreuters.com>.
I think "big" refers to impact to users of the language, not number of files/lines touched. Let's say you change copyright notices; that will affect a lot of files but not a lot of users. Changes like altering the jars structure, how the static type checker works, new language syntax, making compile static on by default are examples of "big changes" that will impact users.
Another example, let's say I want to make "indy" the new default and get rid of the separate classified jars. This is a big change since many, many users are not using 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 <su...@apache.org>
Sent: Sunday, January 27, 2019 3:46 PM
To: dev@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) 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 users, it is a
big change and can not apply the lazy consensus strategy.
Agree with me?
Cheers,
Daniel.Sun
-----
Apache Groovy committer
Blog: https://urldefense.proofpoint.com/v2/url?u=http-3A__blog.sunlan.me&d=DwICAg&c=4ZIZThykDLcoWk-GVjSLmy8-1Cr1I4FWIvbLFebwKgY&r=tPJuIuL_GkTEazjQW7vvl7mNWVGXn3yJD5LGBHYYHww&m=_b29NYtGgrijCwV2rG6I3Bg70IXBiuUWMMCfYpexP9c&s=2DLn8nmHOUU2_Qlx-jzlHxSsQ4dfNUxCljdyis8yXTY&e=
Twitter: @daniel_sun
--
Sent from: https://urldefense.proofpoint.com/v2/url?u=http-3A__groovy.329449.n5.nabble.com_Groovy-2DDev-2Df372993.html&d=DwICAg&c=4ZIZThykDLcoWk-GVjSLmy8-1Cr1I4FWIvbLFebwKgY&r=tPJuIuL_GkTEazjQW7vvl7mNWVGXn3yJD5LGBHYYHww&m=_b29NYtGgrijCwV2rG6I3Bg70IXBiuUWMMCfYpexP9c&s=w8m2klmc3e4i2w9gi8m8TjmQs1RxesdubEgIjd7_8vE&e=
Re: About the lazy consensus on Pull Requests
Posted by "Daniel.Sun" <su...@apache.org>.
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 users, it is a
big change and can not apply the lazy consensus strategy.
Agree with me?
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
Re: About the lazy consensus on Pull Requests
Posted by Cédric Champeau <ce...@gmail.com>.
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
an email to the list and asking for feedback is clearly something to do,
possibly with more explanations about the why and how. And, if you get no
feedback, feel free to ping.
Le dim. 27 janv. 2019 à 22:13, Daniel.Sun <su...@apache.org> a écrit :
> 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
>
Re: About the lazy consensus on Pull Requests
Posted by "Daniel.Sun" <su...@apache.org>.
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
Re: About the lazy consensus on Pull Requests
Posted by Cédric Champeau <ce...@gmail.com>.
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 <su...@apache.org> 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 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 Groovy committer
> Blog: http://blog.sunlan.me
> Twitter: @daniel_sun
>
> --
> Sent from: http://groovy.329449.n5.nabble.com/Groovy-Dev-f372993.html
>
Re: About the lazy consensus on Pull Requests
Posted by "Daniel.Sun" <su...@apache.org>.
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 Groovy committer
Blog: http://blog.sunlan.me
Twitter: @daniel_sun
--
Sent from: http://groovy.329449.n5.nabble.com/Groovy-Dev-f372993.html
Re: About the lazy consensus on Pull Requests
Posted by "Milles, Eric (TR Tech, Content & Ops)" <er...@thomsonreuters.com>.
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 taken.
My opinion is that major changes should start in a branch, go through community review, and thorough testing. At least 2 other PMC members should review and approve the design and impact. And changes labeled as performance improvements should be accompanied by recreateable benchmarks. There are so many changes in Groovy 3 that have been slipped in, that it becomes very difficult to resist the flood; at best I can only manage to pick the 1 most disagreeable change and push back on it.
Take for example the removal of the groovy-all jar. This decision was made very quickly and the build scripts no longer support the ability to create it if an org wants it. That has made it has become very difficult for transition from Groovy 2.4 to 2.5 for IDEs (aka Eclipse) and projects -- especially ones that use the "indy" flavor of groovy-all. We must not only handle the new fixes and features in 2.5 but also the new organization of artifacts -- in Groovy 2.4 we only need to manage a single artifact conflict between dependent projects. To date, our org has not switched to Groovy 2.5 because the friction has been too high trying to get away from groovy-all.
I'm very concerned that Groovy 3 will present a much higher barrier to entry for existing projects.
Re: About the lazy consensus on Pull Requests
Posted by "Daniel.Sun" <su...@apache.org>.
> 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.
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
Re: About the lazy consensus on Pull Requests
Posted by Paul King <pa...@asert.com.au>.
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, 2019 at 8:07 AM Remko Popma <re...@gmail.com> wrote:
> 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 <su...@apache.org> 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 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 objects to the lazy consensus strategy, pls let me know.
> >
> > 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
>
Re: About the lazy consensus on Pull Requests
Posted by Remko Popma <re...@gmail.com>.
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 <su...@apache.org> 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 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 objects to the lazy consensus strategy, pls let me know.
>
> 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