groovy-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Pascal Schumacher <>
Subject Re: [ANN] New committer: Shil Sinha
Date Wed, 21 Oct 2015 06:20:25 GMT
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 
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.


View raw message