Mailing-List: contact dev-help@falcon.apache.org; run by ezmlm
Precedence: bulk
Reply-To: dev@falcon.apache.org
Subject: Re: [DISCUSS] - Cancel Patches & newbie JIRAs
References: 
 <CAKCPnS49bB4b6HLahJfXeFkx2-T1RK+DZW3Q1NDsb9jyJ7KXow@mail.gmail.com>
 <BLU179-W261E2F317794DA4396935AA4D80@phx.gbl>
 <CAJsPzfwOMB=bB+YPSnANNpiuA=mgUZjA-+ttRY-d0W2qFVxZ=w@mail.gmail.com>
 <CAK5w240c4ZvWvXf4HLqqpHi1jKR-jF3fDHoxf=ffnOAQbqC2mw@mail.gmail.com>
 <CAKCPnS4A=ZpiGK88gzjJ6WOFNRFhzEthpxi0t+yEDnZBcT7Nrg@mail.gmail.com>
 <CAK5w243HsweKQvB80NzmJrbQynsivMwXtZnu9dWWJ3j+PX6mqQ@mail.gmail.com>
 <BLU179-W33CAEBCF895423196ACE26A4BB0@phx.gbl>
 <CAKCPnS5JFfaaJYV8dJhB7cCL94psxT7Zg0vqNRMrQ5kCQbUV9g@mail.gmail.com>
From: Siva Thumma <sivatumma@gmail.com>
Content-Type: text/plain;
	charset=us-ascii
In-Reply-To: 
 <CAKCPnS5JFfaaJYV8dJhB7cCL94psxT7Zg0vqNRMrQ5kCQbUV9g@mail.gmail.com>
Message-Id: <117C5066-4C80-44B0-8BF0-B64F060FC35B@gmail.com>
Date: Fri, 12 Jun 2015 14:33:22 +0530
To: "dev@falcon.apache.org" <dev@falcon.apache.org>
Content-Transfer-Encoding: 7bit
Mime-Version: 1.0 (1.0)

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.
>> 
>>