OK, so we will not define any policies / guidelines etc?
Nothing regarding signing
signing as Signed-off for commits is not required by foundation, signing of jars is not related to github
Licensecheck has been automated using dash license tool see "licensecheck" build at the same tycho pull request
Handled by script that's run by Jenkins.
Handled by script that's run by Jenkins
Nothing changes here
Github does automatic linking between issue
There will be more for sure. But we need to execute what we know and at the same time question every extra step needed as it's potentially throwing away contributors.
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.
Cheers
_______________________________________________ eclipse-pmc mailing list
eclipse-pmc@xxxxxxxxxxx To unsubscribe from this list, visit
https://www.eclipse.org/mailman/listinfo/eclipse-pmc
_______________________________________________
eclipse-pmc mailing list
eclipse-pmc@xxxxxxxxxxx
To unsubscribe from this list, visit https://www.eclipse.org/mailman/listinfo/eclipse-pmc