How do we decide on if something is newbie jira ? All in all, We should.
> On 12-Jun-2015, at 9:33 am, Ajay Yadav <[email protected]> wrote: > > 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. >> >>
