> > There shouldn't be any 2_4_x branch. 2_4_X is the one.
Ok, thanks for clearing that up. 2_4_x was created by mistake some months ago, but it should have been > deleted. Does it still exist? Yes, or at least it appears to on the Github mirror. On Wed, Oct 21, 2015 at 12:52 PM, Pascal Schumacher < [email protected]> wrote: > 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 <[email protected]>: > >> 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 < >> <[email protected]>[email protected]> 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 >>> >> >> > >
