+1 Keeping quite != dumb
On 12-Jun-2015, at 6:39 pm, Venkat Ranganathan <[email protected]> wrote: >> 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. >>>> >>>>
