You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@falcon.apache.org by Srikanth Sundarrajan <sr...@hotmail.com> on 2015/06/12 05:45:11 UTC
RE: [DISCUSS] - Cancel Patches & newbie JIRAs
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 <aj...@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 <pa...@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.
Re: [DISCUSS] - Cancel Patches & newbie JIRAs
Posted by Siva Thumma <si...@gmail.com>.
+1
Keeping quite != dumb
On 12-Jun-2015, at 6:39 pm, Venkat Ranganathan <vr...@hortonworks.com> 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" <si...@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 <aj...@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 <sr...@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 <aj...@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 <pa...@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.
>>>>
>>>>
Re: [DISCUSS] - Cancel Patches & newbie JIRAs
Posted by Venkat Ranganathan <vr...@hortonworks.com>.
> 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" <si...@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 <aj...@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 <sr...@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 <aj...@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 <pa...@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.
>>>
>>>
Re: [DISCUSS] - Cancel Patches & newbie JIRAs
Posted by Siva Thumma <si...@gmail.com>.
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 <aj...@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 <sr...@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 <aj...@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 <pa...@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.
>>
>>
Re: [DISCUSS] - Cancel Patches & newbie JIRAs
Posted by Ajay Yadav <aj...@gmail.com>.
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 <sr...@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 <aj...@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 <pa...@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.
>
>