groovy-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Milles, Eric (TR Tech, Content & Ops)" <eric.mil...@thomsonreuters.com>
Subject Re: About the lazy consensus on Pull Requests
Date Sun, 27 Jan 2019 18:44:46 GMT
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.

Mime
View raw message