falcon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Venkat Ranganathan <vranganat...@hortonworks.com>
Subject Re: [DISCUSS] - Cancel Patches & newbie JIRAs
Date Fri, 12 Jun 2015 13:09:22 GMT
> 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" <sivatumma@gmail.com> 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 <ajaynsit@gmail.com> 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 <sriksun@hotmail.com>
>> 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: pallavi.rao@inmobi.com
>>>> To: dev@falcon.apache.org
>>>> 
>>>> 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 <ajaynsit@gmail.com>
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 <pallavi.rao@inmobi.com>
>>>>> 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 <
>>>>>> pavan.kolamuri@gmail.com> 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 <
>>>>>> sriksun@hotmail.com
>>>>>>> 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: ajaynsit@gmail.com
>>>>>>>>> Date: Thu, 14 May 2015 11:24:44 +0530
>>>>>>>>> Subject: [DISCUSS] - Cancel Patches & newbie JIRAs
>>>>>>>>> To: dev@falcon.apache.org
>>>>>>>>> 
>>>>>>>>> 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.
>>> 
>>> 
Mime
View raw message