Ideally we would start to develop a plan / draft document how the new github workflow should look like in general, not only regarding merge policy.
There is nothing to develop, it's about all already written in GitHub documentation. The project is now standing on the shoulders of a giant when it comes to contribution workflows, there is a lot already provided by GitHub and everything always keeps getting better, not much Eclipse specials will be required.
What kind of merges to allow is a project decision but once setup, there is no need to document it further beyond what GitHub already does. FWIW, in all Eclipse other projects I'm working on GitHub, we allow both rebase and squash and are pretty happy with it. The Squash And Merge allows to turn a series of commits into a single one and allows to map the grain that we usually like with Gerrit.
_______________________________________________ eclipse-pmc mailing list eclipse-pmc@xxxxxxxxxxx To unsubscribe from this list, visit