simplify contributing process

[tensorflow]

simplify contributing process

[mdda]

As a timesaver, I wrote up the process in a blog post (mostly because compared to GitHub, the process is poor).

[vrv]

Thanks! We'll use this bug to track the improvements to the contribution process, which we are working on improving.

[bhack]

👍

[bhack]

This Github Gerrit plugin could be evaluated

[bhack]

/cc @lucamilanesio for the plugin

[bhack]

Is this googlebot behaviour on other Google projects on github enought to let collect directly PRs here? If you want to get a pass with Gerrit you can also use the Gerrit github plugin I've already mentioned.

[bhack]

Also nice to evaluate is https://github.com/facebook/mention-bot

[bhack]

@vrv github history/log is full of "TensorFlow: Merging changes from internal". Not very readable.

[martinwicke]

You're correct. We're working on the process. It'll get better.

On Sat, Dec 12, 2015 at 1:57 AM bhack [email protected] wrote:

@vrv https://github.com/vrv github history/log is full of "TensorFlow:
Merging changes from internal". Not very readable.

—
Reply to this email directly or view it on GitHub
#26 (comment)
.

[bhack]

@martinwicke Google
ExoPlayer like github management could be a starting point.

[vrv]

@bhack: fixed our scripts to have more informative / separate commits: https://github.com/tensorflow/tensorflow/commits/master

Hope that helps a bit.

[bhack]

@vrv If you don't rewrite the history and push force now some info will be lost forever here. Related, don't you like the Gerrit plugin I suggested? Why other Google projects like ExoPlayer seems to have a more "natural" relation with github?

[bhack]

The last commit seems to have the same description 091ed8c

[vrv]

@bhack: other projects probably have a more natural relation with github because they only have one source of truth. We have git, and we have our internal repository that we also contribute to actively, so the merge commit is unavoidable when trying to merge two different lineages.

That being said, now that we've moved to individual commits, the merge commit shouldn't be that bad. And it's basically the same as the merge commit from a pull request on github.

[bhack]

@vrv OK but why not the Gerrit github plugin? For the history in last commit I still see the same message see deff101

[vrv]

We are looking at that plugin as one potential option.

The last commit will always be a 'merge commit' message. BVLC/caffe@7953918 is the same, except we don't have a github pull request to reference, since the source isn't from github. Is there a better 'merge commit' message you would like?

[bhack]

@vrv BVLC/caffe@7953918 reference the related PR. I don't know so well Gerrit to tell you what reference get in the script to not let merge description be always the same.

[martinwicke]

@vrv: Should we just include the two commits hashes that were merged in the title?

[bhack]

For subscribers of this Issue the policy on PRs it is changed. Please see the new versions of CONTRIBUTING.md

[bhack]

@vrv In the caffe example you posted we have a description "Add ifdef in CuDNNConvolutionLayer for cuDNN v4". Can we recover some kind of info like this from Gerrit to put in the history. Actually I if want to move through the history I need to always check file changes of internal merges cause descriptions are uninformative.

[vrv]

The merge commit is merging a series of commits from our internal repository. 8b5d9ed is just the merge of the four previous commits, which each individually have the descriptions and change history you want.

For now, I'd suggest just skipping the "Merge commits from internal" commits when looking through the history. Maybe soon we can just have the merge commit message identify which commit hashes it merged so it's more easily linked.

[bhack]

Yes what I mean is if that upstream "gerrit commits" merges are assimilable to a PR as conceptual description. If so probably you could use this concept in the merge description. I.e. many projects ask to squash commits on PRs before merging. But if that are sparse uncorrelated commit I think not description make sense.

[martinwicke]

There is the equivalent of potentially many unrelated PRs in any such
merge, that's why it's hard to find a decent description for the sum of
them.
On Sat, Dec 19, 2015 at 10:42 bhack [email protected] wrote:

Yes what I mean is if that upstream "gerrit commits" merges are
assimilable to a PR as conceptual description. If so probably you could use
this concept in the merge description. I.e. many project ask to squash
commits on PRs before mergining. But if that are sparse uncorrelated commit
I think not description make sense.

—
Reply to this email directly or view it on GitHub
#26 (comment)
.

[vrv]

We've switched to github and there are ongoing improvements to automated testing, etc. But the basics have been improved, so closing this catch-all bug.