I largely agree with Jörg.
I think the expectations set by the "move to github wil boost contributions to Eclipse platform" are not realistic.
I would rather set one clear goal: Eclipse.org don't want bugzilla/gerrit pair anymore, and offshore that functionality to some hosting provider, so let discuss how such move can be done with least possible effort & almost no resources, without breaking the daily work. If that move will attract new contributors - fine, but first we are forced to find a way to replace the aged tooling by someone offered for free by some service provider.
I fully agree that barier to post some trivial nonsence on github/gitlab is almost non existing. However, I don't see how trivial patches would add more *real* contributors because if people don't have enough time to read wiki & start oomph installer, they would not contribute serious fixes, and those who would do it, have usually no troubles with creating bugzilla account and push a gerrit. At the end, same small group of committers will get more work to sort out all the noise of trivial patches coming from github/gitlab.
But I see the point if foundation don't want to host bugzilla/gerrit, we have no other chance as to move.
Just some other points I personally miss in the discussion.
1) Of course gerrit + bugzilla can't compete with github as a project hosting platform, but gerrit is by far superior to github as a *review* tool, where most of the time is spent by committers. I personally definitely will be less effective after moving my Eclipse platform work to github, and I do have github experience, so I know what I'm talking about. Has anyone tried to compare github vs gitlab in this sense? Who offers more advanced review functionality?
2) Looking how many gerrit patch sets are needed in a typical *non-trivial* review, I fear a single github PR will spam the git history with ~20-50+ commits. That would be insane, but could be prevented if we would allow squashing before merge - this need to be considered during move. No idea what gitlab offers here.
3) As usually, the most interesting question is open - who will do all the releng work needed: create new workflow processes, jobs, validation tasks, creating groups/projects, managing users, updating poms, build scripts, jenkins instances, wikis etc? We *hope* someone else will do that, or is this work planned by foundation? That's for sure more than one man-month full time. Do we have already concrete resources assigned to do that work? Should we ask IDE working group here?
4) Should we have *first* a pilot project for some "trivial" repository with small patches trafic, to both github / gitlab, and see how it goes, and AFTER the evaluation decide on the concrete platform?
A candidate would be eclipse.platform.team for example.
Gesendet: Freitag, 15. Oktober 2021 um 10:50 Uhr
An: "'General development mailing list of the Eclipse project.'" <eclipse-dev@xxxxxxxxxxx>
Betreff: Re: [eclipse-dev] RFC: Eclipse TLP migration to Github
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.
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.
Does migration work? I already tried to clone jdt on github but it failed with various errors.
Does Github mean eclipse does vendor lock in to Microsoft or will there be a neutral backup / possibility to migrate back?
Von: eclipse-dev <eclipse-dev-bounces@xxxxxxxxxxx> Im Auftrag von Aleksandar Kurtakov
Gesendet: Donnerstag, 14. Oktober 2021 21:20
An: General development mailing list of the Eclipse project. <eclipse-dev@xxxxxxxxxxx>; Eclipse platform general developers list. <platform-dev@xxxxxxxxxxx>; Eclipse PDE general developers list. <pde-dev@xxxxxxxxxxx>; Eclipse JDT general developers list. <jdt-dev@xxxxxxxxxxx>; Equinox development mailing list <equinox-dev@xxxxxxxxxxx>
Betreff: [eclipse-dev] RFC: Eclipse TLP migration to Github
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 eclipse-dev@xxxxxxxxxxx To unsubscribe from this list, visit https://www.eclipse.org/mailman/listinfo/eclipse-dev