Hi all, Apache NetBeans is already using gitbox ... works very well for us.
Sven Remko Popma <remko.po...@gmail.com> schrieb am Fr., 11. Mai 2018, 18:06: > 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 >>>>> > >>>>> > >>>>> > >>>>> >>>> >>> >
