groovy-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Paul King <pa...@asert.com.au>
Subject Re: [ANN] New committer: Shil Sinha
Date Thu, 22 Oct 2015 07:38:36 GMT
Congrats! Welcome aboard!

On Thu, Oct 22, 2015 at 5:15 AM, Konstantin Boudnik <cos@apache.org> wrote:
> Welcome, good to have you on board!
>
> On Wed, Oct 21, 2015 at 10:18AM, Shil Sinha wrote:
>> 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 <pascalschumacher@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
>> >

Mime
View raw message