Congrats! Welcome aboard!
On Thu, Oct 22, 2015 at 5:15 AM, Konstantin Boudnik <c...@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 <pascalschumac...@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 >> >
