falcon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Ajay Yadav <ajay.ya...@inmobi.com>
Subject Re: [DISCUSS] Moving to github pull request model
Date Thu, 21 Jan 2016 10:20:25 GMT
Pavan,

This is a solved problem. We would like to continue one JIRA = one commit
practice and users will be required squash their commits. Revisiting that
"How to Contribute" section and setting checks to enforce practices is also
one of the preparatory work for this move.


Cheers
Ajay Yadava

On Thu, Jan 21, 2016 at 3:38 PM, Idris Ali <psychidris@gmail.com> wrote:

> +1, good initiative.
>
> Pavan, in the github world we can make use of pull-requests to see what is
> going in a patch.
> Ideally, one patch = one pull request (with multiple commits).
>
> On Thu, Jan 21, 2016 at 3:04 PM, pavan kumar Kolamuri <
> pavan.kolamuri@gmail.com> wrote:
>
> > +1 for this. Only concern i have is there is chance that a single patch
> > will have multiple commits. If we want to see what all changes went in
> one
> > patch we have to look multiple commits. Is there any way to view changes
> of
> > one patch in single go ?
> >
> > On Thu, Jan 21, 2016 at 1:19 PM, Ajay Yadav <ajaynsit@gmail.com> wrote:
> >
> > > Hello everyone,
> > >
> > > Several projects in Apache (the cool kids on the block like SPARK,
> flink
> > > etc.) have moved to github's pull request model instead of the patch
> and
> > > review board approach and more are moving towards that approach. I
> > > personally find this approach much better and some of the advantages
> 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 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. Committers can easily
> commit
> > a
> > >    patch with the click of a button.
> > >    3. *Conflicts - *Users get a real time visibility in whether their
> > >    contribution has conflicts.
> > >    4. *Attribution - *Github's Pull request model allows a stronger
> > >    attribution for the contribution as the author of the patch is the
> > user
> > > who
> > >    submitted the pull request and not the committer who committed this
> to
> > >    master.
> > >
> > >
> > > This will require some preparation work to be done beforehand for
> example
> > > pre commit builds etc. to be configured. If no one has any concerns
> then
> > I
> > > can start figuring out the details and setting infrastructure for it.
> > > Thoughts, suggestions and tips are welcome :)
> > >
> > >
> > > Cheers
> > > Ajay Yadava
> > >
> >
> >
> >
> > --
> > Regards
> > Pavan Kumar Kolamuri
> >
>

-- 
_____________________________________________________________
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.

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message