https://gitbox.apache.org/setup/
On Sat, May 12, 2018 at 12:59 AM, Mario Garcia <mario.g...@gmail.com> wrote: > Remko Could you add a link to Gitbox ? > > El vie., 11 may. 2018 a las 17:52, Remko Popma (<remko.po...@gmail.com>) > escribió: > >> Over at Log4j we just decided to migrate from git-wip-us to gitbox >> <http://mail-archives.apache.org/mod_mbox/logging-dev/201804.mbox/%3CCACmp6komnUBd-ug7durT7PoSAzgRzBy%2BpmGgWM_7BkMeaj6ksw%40mail.gmail.com%3E> >> . >> >> Using gitbox will allow our projects to integrate better with GitHub >>> including the ability to merge PRs directly from the site and the ability >>> to push commits to GitHub and have them be automatically mirrored back to >>> Apache. >> >> >> This may be interesting for Groovy also. >> We haven't made the move yet so I can't give you feedback from >> first-hand experience. >> >> Remko >> >> >> On Sat, May 12, 2018 at 12:32 AM, Mario Garcia <mario.g...@gmail.com> >> wrote: >> >>> *About Static Compilation changes:* >>> >>> I've used the way it's documented in the official documentation, and I >>> agree with Cedric, I don't like having a system property. I see more >>> benefits using the compiler configuration file: >>> >>> - Configuration is more fine grained (apply to all, apply to some >>> classes, apply to some packages...) >>> - All compilation configuration can be found in one place. Having >>> more than one place to do this could be error prone, and harder to >>> maintain. >>> - System properties are normally used when the process should vary >>> depending on the environment. In this case, I'm wondering why I would >>> want >>> to compile my code statically in one environment but dynamically in >>> another. Maybe there is a case for that, but to me is weird. >>> >>> *About Daniel response:* >>> >>> I'm so sad to hear that Daniel. In the past few years I've been hearing >>> only amazing things coming from your contributions. Like someone has >>> mentioned, Groovy 3 wouldn't be the same without you. I really hope you >>> could reconsider your decision and keep contributing to Groovy. >>> >>> *About doing commits on master:* >>> >>> Reading the "Contributing code" section, at groovy-lang.org it seems >>> everybody should be creating a local branch and to a MR afterwards over the >>> remote version of that local branch. So (again, reading the >>> documentation) nobody should be adding commits to master directly. >>> >>> I think merge requests are essential. I'm reading Jochen is saying that >>> this is not very straight forward with Github. Could anyone please explain >>> why ? Knowing the pains may help finding the solution. >>> >>> My two cents >>> Mario >>> >>> El vie., 11 may. 2018 3:42, Thibault Kruse <tibokr...@googlemail.com> >>> escribió: >>> >>>> It seems a bit weird to leave this thread dangling after the dramatic >>>> entry scene. >>>> >>>> The activity on master branch seems to indicate some changes were >>>> decided: >>>> >>>> danielsun1106 committed 2 days ago : Revert "GROOVY-8543: Support >>>> setting compileStatic by default via sys… >>>> danielsun1106 committed 18 hours ago : GROOVY-7204: Static type >>>> checking and compilation fail when multiple … >>>> danielsun1106 committed 14 hours ago : Simplify finding generics >>>> implementation class >>>> >>>> However, the meta-concern by Cedric was not addressed it seems. Why is >>>> anyone directly working on the master branch of groovy? >>>> Is there a technical reason for this, rather than using feature >>>> branches, code reviews, and merge approvals? >>>> Or is it just that nobody would have time to review in a timely >>>> fashion anyway, so it's either that or zero progress? >>>> >>>> >>>> On Tue, May 8, 2018 at 7:43 AM, MG <mg...@arscreat.com> wrote: >>>> > On 07.05.2018 17:54, Cédric Champeau wrote: >>>> >> >>>> >> I'd typically very much prefer a custom file extension for example. >>>> > >>>> > >>>> > That would be my preferred way to give anyone a simple mean to choose >>>> static >>>> > compilation as the default for a Groovy file. Afair the counter >>>> argument >>>> > was, that Groovy compiles any file with any extension in dynamic mode >>>> by >>>> > default, so this might be a breaking change if someone has used the >>>> picked >>>> > extension for his files. Groovy 3.0 might be the right spot to >>>> introduce >>>> > something like this, since there will be breaking changes anyway... >>>> > >>>> >> That said, since I'm not contributing code anymore (my last >>>> contribution >>>> >> was rewriting most of the build, which I hope was helpful), >>>> > >>>> > >>>> > Any improvement/speedup of the Gradle build was _definitely_ >>>> appreciated :-) >>>> > >>>> >> I'm happy to step down and let you work as you wish. >>>> > >>>> > >>>> > This is tricky: One cannot agree with just any direction someone who >>>> invests >>>> > the time to advance Groovy wants to take it too, that would be taking >>>> > Doocracy too far, imho, and might lead to a Groovy which is much >>>> worse than >>>> > it could be. >>>> > In this particular case I am torn: I think we could definitely live >>>> with the >>>> > system property, I don't feel there is a large probability that it >>>> will >>>> > break anything. On the other hand, using the existing mechanism, or >>>> > introducing a static compilation source file extension, or a compiler >>>> switch >>>> > seem to me to be the better choices - but maybe Daniel can explain >>>> why he >>>> > went with the property approach ?-) >>>> > >>>> > Cheers, >>>> > mg >>>> > >>>> > >>>> > >>>> >>> >>
