nifi-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Mike Thomsen <>
Subject Re: [DISCUSS] Addressing Lingering Pull Requests
Date Thu, 01 Feb 2018 14:31:05 GMT
It looks like there are at least 10 new processors and services in the
backlog, and quite a few modifications to existing ones.

Something I think would really help here is to expand the scope of
requirements for submitting a new processor for code review to include:

1. docker-compose file that sets up a complete development environment w/
appropriate port mappings that just work when used with NiFi running
outside of Docker on the reviewer's machine.

2. A sample flow, a really KISS example w/ GenerateFlowFile or something
that spits out a query or sample that can let the reviewer really see the
submitter's idea of what the input should look like.

Whether those are stored on a Wiki or in the Git repo doesn't really
matter. I think submitting those artifacts will really reduce the burden of
quickly going from "LGTM, JUnits seem to run" to "OK, I see it actually
running as expected."

On Tue, Jan 30, 2018 at 12:38 AM, James Wing <> wrote:

> This is a great idea, Mark, thanks for proposing it.  30 days after last
> review comment seems like a good, enforceable standard.
> James
> On Mon, Jan 29, 2018 at 8:29 AM, Mark Payne <> wrote:
> > All,
> >
> > We do from time to time go through the backlog of PR's that need to be
> > reviewed and
> > start a "cleansing" process, closing out any old PR's that appear to have
> > stalled out.
> > When we do this, though, we typically will start sending out e-mails
> > asking if there are
> > any stalled PR's that we shouldn't close and start trying to decipher
> > which ones are okay
> > to close out and which ones are not. This puts quite an onus on the
> > committer who is
> > trying to clean this up. It also can result in having a large number of
> > outstanding Pull Requests,
> > which I believe makes the community look bad because it gives the
> > appearance that we are
> > not doing a good job of being responsive to Pull Requests that are
> > submitted.
> >
> > I would like to propose that we set a new "standard" that is: if we have
> > any Pull Request
> > that has been stalled (and by "stalled" I mean a committer has reviewed
> > the PR and did
> > not merge but asked for clarifications or modifications and the
> > contributor has not pushed
> > any new commit or responded to the comments) for at least 30 days, that
> we
> > go ahead
> > and close the Pull Request (after commenting on the PR that it is being
> > closed due to a lack
> > of activity and that the contributor is more than welcome to open a new
> PR
> > if necessary).
> >
> > I feel like this gives contributors enough time to address concerns and
> it
> > is simple enough
> > to create a new Pull Request if the need arises. Alternatively, if the
> > contributor realizes that
> > they need more time, they can simply comment on the PR that they are
> still
> > interested in
> > working on it but just need more time, and the simple act of commenting
> > will mean that the
> > PR is no longer stalled, as defined above.
> >
> > Any thoughts on such a proposal? Any better alternatives that people have
> > in mind?
> >
> > Thanks
> > -Mark

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