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 16:52:03 GMT
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 < 
> <>>:
>     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
>         <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