> How do we decide on if something is newbie jira ? Generally the committers with good knowledge of the area the issue is addressing can make the call
Venkat On 6/12/15, 2:03 AM, "Siva Thumma" <[email protected]> wrote: >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. >>> >>>
