I got mixed feelings:
Why? I doubt a migration to a more used platform will automatically attract new contributors. I perceive the committers community (language barrier, mindset, soft skills, empathy and available time for other people’s contribution, response time) as a bigger obstacle then the technical barrier. That totally includes me on both sides. Eclipse has very skilled committers. That’s good but that leaves very tiny room for imperfection. Months for reviews of minor issues while the bigger issues in the existing code remain. Perfect code is good. But it does not mean a perfect product. With every contributor lost due to the high expectations on the code quality the community losses people and the future work they might do. Even bad code contributions can be valuable in a sense that the contributor gets involved. If the initial contributors would have had the same level of clean-coding aims as today, then the current Eclipse IDE would not be at the same feature completeness as is. All the dirty hacks somehow work good enough for the average user.
Will github solve nitpicking? I doubt it will by its own. There are robots that do autoformat code, solve whitespace “issues”, automatically add copyright, … all that annoying stuff. But it won’t come just by moving to github, it would be equally possible with gerrit.
The question here is did you lose any time trying to contribute to eclipse and its usage of not so community standard tools?
Regarding nitpicking - IMHO this is result of burnout in many of the committers where we are afraid we would have to maintain and fix regressions while we can hardly find time to go for a coffee. The only solution to that is get more contributors and we should try every way possible to achieve that even if some changes give us a single digit better chance for that.
Regarding autoformat, whitespace issues and etc. - JDT has the beautiful concept of save actions and some of us are pushing to automate more and more (e.g. just in platform.ui repo https://git.eclipse.org/c/platform/eclipse.platform.ui.git/log/?qt=grep&q=save+action
). It might not be the fastest way but by going incrementally it allows us to have traceability while reducing the burden on developers every next iteration. But we can't just enable every save action and compiler warning at the same time as it would literally rewrite every file. Help on cleaning up our codebase is more than welcome and most projects are quite acceptive to that within their limitations like available reviewers free time, next Java release concerns for JDT and etc.
I don’t mind which tools eclipse uses, as long as they work consistent together.
Please make sure PDE’s „Import from Repository“ works with github.
I'm not sure what you mean here. Please open a bug report with failing case and we can continue there.
Does migration work? I already tried to clone jdt on github but it failed with various errors.
After all initial migration aka push jdt git repo is not an issue. Please tell us what/how is failing (maybe in a separate thread to not pollute this one).
Does Github mean eclipse does vendor lock in to Microsoft or will there be a neutral backup / possibility to migrate back?
We (Eclipse PMC) have been discussing migration to Github so we try to get closer to the bigger developer community and at the same time enhance the tooling we use daily.
We have prepared a document  listing why, what, when, how according to our best knowledge but we are looking for your comments, ideas, etc. so together we choose the best path forward for Eclipse IDE development process.
P.S. All communication channels are fine - comments on the document, mailing list discussions and even calls to discuss things.
eclipse-dev mailing list
To unsubscribe from this list, visit https://www.eclipse.org/mailman/listinfo/eclipse-dev