falcon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Srikanth Sundarrajan <srik...@hotmail.com>
Subject RE: [DISCUSS] - Cancel Patches & newbie JIRAs
Date Fri, 12 Jun 2015 03:45:11 GMT
Should we adopt this ?

Regards
Srikanth Sundarrajan

> Date: Fri, 15 May 2015 15:34:15 +0530
> Subject: Re: [DISCUSS] - Cancel Patches & newbie JIRAs
> From: pallavi.rao@inmobi.com
> To: dev@falcon.apache.org
> 
> I'm trying to avoid multiple cycles of patch upload -> review -> update
> patch, by getting as many comments up front.
> 
> Also, to me, when I submit a patch, it is an indication that it is ready
> for review. Similarly, when I cancel my patch, it is an indication that I'm
> reworking my patch.
> 
> Committers and the rest of the contributors can always be the second line
> of defense, if one of us notices any JIRA for too long in PATCH AVAILABLE
> even after one review, we can always cancel with a comment.
> 
> On Fri, May 15, 2015 at 3:08 PM, Ajay Yadav <ajaynsit@gmail.com> wrote:
> 
> > Thanks for the comments Pallavi!
> >
> > I think the patch should be cancelled by the reviewer/committer. I
> > understand your concern that the rest of the community may miss reviewing
> > the patch but the problem that we are facing is actually the opposite. Some
> > patches lie around for a long time without getting any feedback, they get
> > buried under other JIRAs. Sometimes people loose enthusiasm to contribute
> > if they don't see any progress or feedback on their JIRA. It has happened
> > in Falcon and as a community we have often admitted that we need to work
> > more on reviewing JIRAs and giving more prompt feedback. People can always
> > go to open review board requests and review all open requests for Apache
> > Falcon if they want. One can also review JIRAs before committers/reviewers
> > get a chance to review or commit it and it will be highly appreciated. One
> > will have the chance to review the patch once again when newer patch
> > becomes available. Also, new comers might not be familiar with our JIRA
> > workflow and might not know that they have to cancel the patch. Hence I
> > believe that onus of cancelling the patch should be on the reviewer. In my
> > opinion this also seems to be the more common practice.
> >
> > A user might not start rework on the patch in short time because of several
> > possible reasons so I feel it should be cancelled immediately. It's just a
> > state change to say "hey I need some more inputs from you before I can take
> > this JIRA further". Cancelling it after a few days doesn't solve the
> > purpose of keeping the queue short and giving all JIRAs a chance to get
> > reviewed. Also, some of us review all Patch Available JIRAs whenever they
> > get time, there is no way for them to get to the JIRAs which haven't been
> > reviewed even once. There is no way to know without opening the JIRAs if
> > the previous feedback is incorporated or not. All committers/reviewers will
> > have to continuously keep checking those JIRAs .
> >
> >
> >
> >
> > On Fri, May 15, 2015 at 1:42 PM, Pallavi Rao <pallavi.rao@inmobi.com>
> > wrote:
> >
> > > Regarding canceling a patch, +1 for it. But, I think we need to layout
> > the
> > > guidelines a little more clearly as to who cancels the patch and when
> > > should it be cancelled.
> > >
> > > If a patch is cancelled by a reviewer/committer, the rest of the
> > community
> > > may miss reviewing the patch. And, when the patch is updated, the
> > community
> > > may provide further or conflicting comments. So, I suggest that the owner
> > > of the JIRA cancel the patch.
> > >
> > > When should one cancel the patch? A few days after the first reviewer has
> > > provided his comments, giving some time for others to review it. The time
> > > interval again can be left to the discretion of the owner, based on the
> > > size and nature of the patch. Basically, he/she will cancel the patch
> > when
> > > re-work on the patch begins.
> > >
> > > As always, comments welcome.
> > >
> > > On Fri, May 15, 2015 at 12:49 PM, pavan kumar Kolamuri <
> > > pavan.kolamuri@gmail.com> wrote:
> > >
> > > > +1 for this approach . It will be good for new one's to start
> > contribute
> > > as
> > > > well .
> > > >
> > > > On Thu, May 14, 2015 at 4:05 PM, Srikanth Sundarrajan <
> > > sriksun@hotmail.com
> > > > >
> > > > wrote:
> > > >
> > > > > I know few other projects at ASF follow the practice of cancelling
> > > > patches
> > > > > when more work is required on it to keep the "Patch Available" queue
> > > > small
> > > > > and with something that requires immediate attention. Am +1 on this.
> > > > >
> > > > > +1 for tagging jira's with "newbie" as well. One needs to update
the
> > > > cwiki
> > > > > article in How To contribute accordingly as well.
> > > > >
> > > > > Regards
> > > > > Srikanth Sundarrajan
> > > > >
> > > > > > From: ajaynsit@gmail.com
> > > > > > Date: Thu, 14 May 2015 11:24:44 +0530
> > > > > > Subject: [DISCUSS] - Cancel Patches & newbie JIRAs
> > > > > > To: dev@falcon.apache.org
> > > > > >
> > > > > > Hi Everyone,
> > > > > >
> > > > > > Currently we have around 30 issues in Patch Available state.
To
> > keep
> > > > this
> > > > > > queue short and to distinguish the issues which haven't been
> > reviewed
> > > > > from
> > > > > > the issues which have been reviewed but need further work, I
> > propose
> > > > that
> > > > > > we should change the state to Open (by cancelling the patch).
This
> > > way
> > > > we
> > > > > > can review patches which need to be looked at more efficiently
and
> > > > > > frequently.
> > > > > >
> > > > > > My second suggestion is to start creating some "nice to have"
JIRAs
> > > > which
> > > > > > are suitable for new comers and label them as *newbie. *This
will
> > > help
> > > > > new
> > > > > > comers who want to contribute to the project. Experienced
> > > contributors
> > > > > > should avoid assigning these JIRAs to themselves unless absolutely
> > > > > > necessary. Help from other committers towards creating more
newbie
> > > > JIRAs
> > > > > is
> > > > > > very welcome.
> > > > > >
> > > > > > Thoughts?
> > > > > >
> > > > > > 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.
> > >
> >
> 
> -- 
> _____________________________________________________________
> 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