On 20 Nov 2012, at 16:24, michael keith wrote:
Call me old-fashioned, or just plain scatter-brained, but I
prefer/need to use the bug reporter to keep track of contributions
anyway. Any alternatives that exist beyond that path just confuse me
and have a high probability of getting by me.
I agree with that too, just forgot to mention it.
On 20/11/2012 11:17 AM, Glyn Normington wrote:
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
_______________________________________________
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
|
