+0 from my side. I agree moving to github PR is a good idea but I see few minor issues with github pull req model.
Review comments will be automatically closed if any change happens to reviewed line irrespective of whether developer fixed review comment fully or not. If pull/review request has lots of review comments then it is very hard to track it via github pull request model. It is very easy to view all review comments(open & closed) with drop down. User will loose freedom of frequent uploads to his own github account(lots of small commits(i.e. half complete tasks) to save his work) after raising a pull request because every push to his own github account will be reflected immediately on pull request. I feel reviewer will also not be sure most of the times when the modified pull req can be reviewed until develop confirms. On Mon, Jan 25, 2016 at 5:21 PM, Deepak Kumar Barr (Tech_BLR) < [email protected]> wrote: > +1. It would be a good move. > > Regards, > Deepak Kumar Barr > Bigfoot-Apps > > On Mon, Jan 25, 2016 at 12:29 AM, Ankeet Maini <[email protected]> > wrote: > > > +1 to PRs! > > > > -----Original Message----- > > From: "Ajay Yadav" <[email protected]> > > Sent: 25-01-2016 12:21 AM > > To: "[email protected]" <[email protected]> > > Subject: [DISCUSS] Moving to Github pull Request model > > > > Hello everyone, > > > > On popular demand Apache provided integration with github pull requests > and > > several Apache projects (the cool kids on the block like SPARK, Kafka, > > Flink etc.) have moved to github's pull request model instead of the > patch > > and reviewboard approach and more are moving towards that approach > (Apache > > Falcon etc.). Some of the advantages of this approach are as follows > > > > 1. *Familiarity* *-* Due to the popularity of github in open source > > projects lot more users are familiar with the pull request model than > > the patch/ review board based approach. > > 2. *Ease - *Users don't have to create a review board request and at > the > > same time attach the patch to JIRA also. Although lens has some > > automation, > > it still requires learning a new tool for contributors. > > 3. *Conflicts and Test Status - *Users get a real time visibility in > > whether their request can be merged cleanly and the status of tests if > > their changes are applied. > > > > > > Should we also move to pull request model? > > > > This will require some preparation work to be done beforehand for example > > pre commit builds on pull requests will need to be configured. I happen > to > > have some experience in this process (I recently did this for Apache > > Falcon) and if everyone agrees to move to this new model then I can > > volunteer for it. > > > > > > Cheers > > Ajay Yadava > > > > -- > > _____________________________________________________________ > > The information contained in this communication is intended solely for > the > > use of the individual or entity to whom it is addressed and others > > authorized to receive it. It may contain confidential or legally > privileged > > information. If you are not the intended recipient you are hereby > notified > > that any disclosure, copying, distribution or taking any action in > reliance > > on the contents of this information is strictly prohibited and may be > > unlawful. If you have received this communication in error, please notify > > us immediately by responding to this email and then delete it from your > > system. The firm is neither liable for the proper and complete > transmission > > of the information contained in this communication nor for any delay in > its > > receipt. > > > -- ------ Thanks, Raju Bairishetti, www.lazada.com
