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.
