groovy-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From C├ędric Champeau <>
Subject Re: [ANN] New committer: Shil Sinha
Date Wed, 21 Oct 2015 14:19:31 GMT
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.
>> -Pascal

View raw message