I'm not sure many of us are convinced that GitHub itself is a magic
bullet despite anecdotes to the contrary.
I have the impression that the majority of committers who also happen to use GitHub for other (Eclipse or not) projects do agree that GitHub is an enhancement for the project community at large over Gerrit.
People who are not familiar with GitHub seem more driven by fear of change.
Surely no one will be contributing to any part
of the platform without using Eclipse, or am I missing something?
You're missing that many quick-fixes (labels, typos, documentation, releng change...) are actually not requiring the Eclipse IDE to be implemented easily. In some cases, those quick-fixes can be produced via GitHub editor, even on a phone in a bus. That brings the highest ROI to contributors and requires 0 extra workflow learning to contribute.
Then the CI stack pops-in to perform the automated validation (as users don't use "stronger" tools, there contribution are more likely to cause errors so this validation phase becomes more important).
My sense continues to be that the platform team's own "not invented
here, or not invented by us" aversion is the primary problem of a missed
opportunity here. Folks just don't feel a need or desire to promote
something that's simple and works well, nor to contribute to
improvements if it doesn't 100% suit the ideals.
If this comment is about Oomph, then Oomph is mentioned/promoted in
https://wiki.eclipse.org/Platform/How_to_Contribute . And I don't think Platform as a project has prevented anyone interested from promoting Oomph in other documentation, talks or whatever. So unless I missed something here, your comment seems lacking substance.
Instead I see notes
about "one click cloning a repo" being really cool when we have "one
click provision an entirely functional IDE ready for contribution"
already available for a long time. Why is that I wonder?
If you're referencing
https://github.com/mickaelistria/redirctToEclipseIDECloneCommand/ , then it's a pity you fail at seeing the difference: this one is supposed to work for any GitHub project without *any* Eclipse/Oomph specific file addition and maintenance. This difference is major in the scope and goals of clone link vs Oomph.
However, as mentioned earlier when I sent a note about 1-click link clone, the link approach would be totally viable for Oomph as well: if some Oomph contributor were interested, it would be totally possible to generate an Eclipse link command as well to import a Oomph profile and open the wizard to provision it in the IDE. It's just a matter of someone interested in doing it. Once this is possible, such link would be a great addition to Eclipse Platform project documentation pages. And this can already work independently of Gerrit/GitHub, so there is no barrier preventing it.
What's to learn? Most users are already familiar with using it via the
installer.
People I've seen using the installer basically stick to the product selection page and apply stuff. It's good, but I don't think those people get a sense that the installer does more than an installation and that the underlying Oomph can do full provisioning.
In any case, by implication, apparently what people really
care to do is learn how to install and then use Eclipse (the right one
with PDE) as well as EGit to clone the correct URLs. Then they know to
magically import the correct and only appropriate projects into the
workspace from that clone, without reading anything. Then these highly
motivated users know to set up a proper API baseline from their
ethereal knowledge. When faced with the sea of red errors, they continue
to try to figure out (without reading anything), how to make them go
away before they can make their first attempt at a contribution. (Oh
yes, and don't forget to copy/renamed the SWT .classpath file manually,
without having read something to describe that tiny but fundamental step.)
See comment above about many interesting changes not requiring all those tools and better handled by GitHub online editor.
This whole premise seems beyond questionable to me. Instead, let's
focus on moving to GitHub as a magic bullet, with no technical
discussion about the merit of that because it's a social decision not a
technical decision and the conclusion is foregone...
Many technical aspects were discussed, blocker concerns raised, tickets open to EMO or GitHub... You're neglecting those part of the discussions were/are happening; but it's been there and it's still open.
Moving to GitHub is indeed entirely a social decision; it's about community growth. Once the technical concerns are mitigated, it becomes really a decision of "do we want the project stay in our hands of Eclipse old-timers or passionate/paid Eclipse contributors" or "do we want to make the project open to a wider world". To me, sticking to marginal contribution workflow is going to hurt severly the Eclipse project contributor diversity in the next ~5 years and put the project at risk of becoming unstaffed and irrelevant; only the later approach can make the Eclipse Platform project sustainable for a longer time; so, selfishly, it's also the approach that will guarantee me -and I think others- more paid years working for Eclipse IDE.
