Welcome Shils! :)
Am 20.10.2015 um 22:41 schrieb Shil Sinha:
BTW, I think it's still a good idea to use PRs for a short period
of time, so that you can accommodate with our dev process. In
particular, how patches should be applied on master and cherry
picked on maintenance branches.
I committed a small change to master and cherry picked it to 2_4_X
yesterday, hope that was ok.
Yes that was fine. In my opinion you do not need to create a pull
request for small changes like this one
(https://github.com/apache/incubator-groovy/commit/d6497413f6e94f9b66e0d2853ef1ac21d00c1f98).
I'll continue using PRs going forward for the time being.
As far as merging pull requests, I read through a few of the dev
threads from when Groovy migrated to Apache, but couldn't find a
definitive workflow. Is that documented anywhere? If not, I can write
it as I get familiar.
I use
git fetch https://github.com/<contributor>/incubator-groovy.git
<pull-request-branch>
git cherry-pick <commit(s) of the pull request>
git commit -a --amend --> to add "(closes #<pull-request-number>) at the
end of the title"
BTW: I prefer a model where committers are also supposed to go through
pull request / review processes. I believe that does not decrease
productivity, but has a range of beneficial effects. Becoming a
committer should ideally just mean the ability to approve and merge
other people's pull requests/patches.
I find this beneficial as well, for code changes. It's a useful way to
keep up with the codebase, rather than just browsing commits.
I also think this is beneficial for improving quality and spreading
knowledge. But the reviews have to be done in a timely manner and at the
moment we are to slow to even review pull request (imho). So we use this
model only of for very important changes or when are unsure about a change.
-Pascal
