2_4_x was created by mistake some months ago, but it should have been
deleted. Does it still exist?
Am 21.10.2015 um 16:19 schrieb Cédric Champeau:
There shouldn't be any 2_4_x branch. 2_4_X is the one.
2015-10-21 16:18 GMT+02:00 Shil Sinha <shil.si...@gmail.com
<mailto:shil.si...@gmail.com>>:
Thanks Pascal! The only other question I have is, what's the
difference between the 2_4_X and 2_4_x branches?
On Wed, Oct 21, 2015 at 2:20 AM, Pascal Schumacher
<pascalschumac...@gmx.net <mailto:pascalschumac...@gmx.net>> wrote:
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
