On 20 Nov 2012, at 16:04, Wayne Beaton wrote:
Do you feel that the value (e.g. IP safety) of the requirement to
set the committer field to a real project committer's credentials is
worth the cost?
Yes, just about. The cost is the initial effort of learning how to fiddle with multiple remotes (easy to do and a useful skill) and use git filter-branch (scary but useful). After that, it's fairly painless - at least for simple pull requests that have not been merged from master multiple times.
For me there is a real benefit of this process - if a 3rd party commit somehow slips into my local git repository, e.g. because I wanted to run it before accepting the pull request, I can't then accidentally push it to eclipse.org. Although this hasn't happened to me in practice, it would then remind me to do the due diligence.
i.e. is removing that restriction a conversation worth having/battle
worth fighting?
I can imagine some people would like to fight that battle, but I personally don't want to. If someone else wants to, I'm sure I would be fairly happy with the outcome. I'd just keep more "yellow stickies" around whenever processing a 3rd party commit.
Wayne
On 11/20/2012 10:13 AM, Glyn Normington wrote:
Hi Wayne
On 19 Nov 2012, at 16:58, Wayne Beaton wrote:
The eclipse.org Git
repositories have to [be] the "main" project repositories.
Anything that flows back into the eclipse.org repositories
are subject to the IP Due Diligence process.
Theoretically, you should be able to accept contributions
into the GitHub repository and not flow them back into the eclipse.org repository.
Whether or not that makes sense is up to the project members
to decide.
Some observations about handling a pull request at github.
A committer needs to change the committer of the commits in
the pull request in order to be able to push those commits to eclipse.org.
This necessarily creates fresh commits with different SHAs to
the originals.
Therefore, I would strongly recommend committers to accept
pull request into their local git repository (by adding a remote
and pulling from that remote), rewrite the committer (but not
the author) of each commit to themselves, and after completing
due diligence, push to eclipse.org. The commits will
then be mirrored across to the github mirror automatically.
If a committer was to accept a pull request "directly" (i.e.
automatically using the github web interface) at github, they
would still need to pull the commits down to their local git
repository and rewrite them before being able to push them to eclipse.org.
After mirroring, there would then be duplicate commits on the
github mirror, which could cause confusion or worse. So they
would trade off a bit of automation against adding a remote, but
could end up in confusion.
NB. We discussed this at today's Gemini project call and the
consensus among the project leads present was that they also
would not accept pull requests directly at github.
Regards,
Glyn
_______________________________________________
gemini-dev mailing list
gemini-dev@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/gemini-dev
_______________________________________________ gemini-dev mailing list gemini-dev@xxxxxxxxxxx https://dev.eclipse.org/mailman/listinfo/gemini-dev
|