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 <>:
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 <> 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 (

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<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.