falcon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Ajay Yadav <ajayn...@gmail.com>
Subject Re: [DISCUSS] - Cancel Patches & newbie JIRAs
Date Fri, 15 May 2015 09:38:57 GMT
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.
>

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message