groovy-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Graeme Rocher <graeme.roc...@gmail.com>
Subject Re: What the... static compile by default
Date Mon, 07 May 2018 16:48:18 GMT
Hi Cedric,

I don't think anybody wants anybody to step down (whether that be you,
Daniel or whoever) and you make valid points about processes that
could be improved. I would however encourage you to re-read your
original email to understand how it may impact others. Maybe adjust
the tone of your emails since this is not the first email of that
nature. Starting off being the bad cop and usage of phrases like "when
the heck" it came across as aggressive and I can understand why Daniel
and possibly others would feel discouraged. I know however your
intention is good and maybe it is a language thing. We all want the
best for Groovy at the end of the day.

Cheers

On Mon, May 7, 2018 at 5:54 PM, Cédric Champeau
<cedric.champeau@gmail.com> wrote:
> Hi Daniel and sorry you are "tired". Maybe the tone I used was
> inappropriate?, but it wasn't directed at you personally. I'm quite
> surprised to see some things like that happening on master without any
> discussion on the MLs. Maybe that's because I expect too much from the
> developers of Groovy, but I strongly think we owe better to the community,
> and in particular code quality. In that area, we don't have _any_ peer
> review. Everybody works on master, and I think that's a bad idea. Things
> like this happen, but we have to realize that Groovy is used by tens of
> thousands of developers, so any choice we make has consequences. So, if we
> had peer reviews, questions like this wouldn't happen. Should you want to
> introduce a feature, it wouldn't go to master without a review from another
> committer/PMC. Same for Paul, and same for me. I think it's too easy to push
> to master today, and this bites us.
>
> So to come back to the original topic of this thread, I never saw that
> ticket, and, for one, don't read every ticket out there, I mostly have time
> to follow discussions on the MLs. So I can react when I see something that
> looks wrong to me. Here, I don't have the impression that the ticket even
> comes to any conclusion, it just "happened". I still think the approach is
> incorrect, I'd typically very much prefer a custom file extension for
> example. And if it's just for internal testing, the compiler configuration
> already has everything we need without having to rely on a system property.
> We have to realize that adding a property without testing it in combination
> with other flags is a problem too.
>
> That said, since I'm not contributing code anymore (my last contribution was
> rewriting most of the build, which I hope was helpful), I'm happy to step
> down and let you work as you wish. I mostly want to make sure Groovy goes in
> the right direction. If I'm a blocker, I have no problem with that.
>
> 2018-05-07 17:40 GMT+02:00 Jeff Scott Brown <brownj@objectcomputing.com>:
>>
>>
>>
>> On 2018/05/07 14:59:09, "Daniel.Sun" <sunlan@apache.org> wrote:
>>>
>>> Hi Cédric,
>>>
>>>       Feel free to remove any code.
>>>       To be honest, I am really tired.
>>>       Bye Groovy community.
>>>
>>> Cheers,
>>> Daniel.Sun
>>>
>> }
>>
>> Daniel,
>>
>> Please reconsider.  I think the tone at the beginning of this thread was
>> unfortunate and I expect that has contributed to your frustration.
>>
>> Your contributions are very much appreciated by the community and you
>> should be proud of the work you are doing with Groovy.  It would be a real
>> shame to lose your enthusiasm and contributions to this great language and
>> great ecosystem.  I mean that sincerely.
>>
>> Let me know whatever I can do to help.
>>
>> Thanks for all of your great work.  Well done sir!
>>
>>
>>
>>
>> JSB
>> --
>> Jeff Scott Brown
>> OCI Partner and Principal Software Engineer
>> OCI Grails Practice Lead
>>
>> Autism Strikes 1 in 166
>> Find The Cause ~ Find The Cure
>> http://www.autismspeaks.org/
>
>



-- 
Graeme Rocher

Mime
View raw message