We discussed it in the syncup. We agreed to cancel patches if they are not ready for review or need more work to be done.
On Fri, Jun 12, 2015 at 9:15 AM, Srikanth Sundarrajan <[email protected]> wrote: > Should we adopt this ? > > Regards > Srikanth Sundarrajan > > > Date: Fri, 15 May 2015 15:34:15 +0530 > > Subject: Re: [DISCUSS] - Cancel Patches & newbie JIRAs > > From: [email protected] > > To: [email protected] > > > > 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 <[email protected]> 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 <[email protected]> > > > 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 < > > > > [email protected]> 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 < > > > > [email protected] > > > > > > > > > > > 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: [email protected] > > > > > > > Date: Thu, 14 May 2015 11:24:44 +0530 > > > > > > > Subject: [DISCUSS] - Cancel Patches & newbie JIRAs > > > > > > > To: [email protected] > > > > > > > > > > > > > > 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. > >
