nifi-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Aldrin Piri <aldrinp...@gmail.com>
Subject Re: [DISCUSS] Addressing Lingering Pull Requests
Date Tue, 30 Jan 2018 02:18:56 GMT
Hello,

Yes, this is unrelated (or at least I believe) and is an effort within the
ASF.  There is not a lot of information available, but the associated page
is https://gitbox.apache.org/.

On Mon, Jan 29, 2018 at 9:11 PM, Sivaprasanna <sivaprasanna246@gmail.com>
wrote:

> Apologies. I’m very new to contributing so I’m not aware of gitbox. One
> question this gitbox that is being discussed here is in no way related to
> this one http://www.gitboxapp.com/. Correct?
>
> On Tue, 30 Jan 2018 at 1:13 AM, Pierre Villard <
> pierre.villard.fr@gmail.com>
> wrote:
>
> > Agree with everything being said here. We clearly need to better manage
> the
> > number of opened PRs and also remind the community that contributing code
> > is great but that helping in the review process will create a virtuous
> > circle and benefit the community.
> >
> > Pierre
> >
> > 2018-01-29 18:48 GMT+01:00 Joe Witt <joe.witt@gmail.com>:
> >
> > > maybe kick that gitbox thread to a vote since it is decent change to
> > > the workflow.
> > >
> > > Thanks
> > >
> > > On Mon, Jan 29, 2018 at 12:45 PM, Aldrin Piri <aldrinpiri@gmail.com>
> > > wrote:
> > > > Gitbox was favorably received when we discussed it prior:
> > > > https://lists.apache.org/thread.html/de5e103994f356b1b8a572410938ee
> > > f44af8cb352210e35305c04bc9@%3Cdev.nifi.apache.org%3E
> > > >
> > > > I would be in favor of moving ahead with it and would be happy to get
> > > > things moving if it still seems agreeable.
> > > >
> > > > --aldrin
> > > >
> > > > On Mon, Jan 29, 2018 at 11:46 AM, Bryan Bende <bbende@gmail.com>
> > wrote:
> > > >
> > > >> I definitely agree with all of these points.
> > > >>
> > > >> With our current setup, the only way a committer can close a PR is
> by
> > > >> issuing a commit with the magic "This closes ..." clause.  The
> > > >> submitter of the PR is the only one who can actually close it in
> > > >> GitHub.
> > > >>
> > > >> I don't want to hijack the discussion with a different topic, but
it
> > > >> might be worth considering switching to the ASF's GitBox integration
> > > >> [1], which I believe lets us use Github as a real repository, rather
> > > >> than just a mirror.
> > > >>
> > > >> It seems like it would make it easier to manage the PRs in the event
> > > >> that we did implement a policy like Mark and Joe described.
> > > >>
> > > >> [1] https://gitbox.apache.org/repos/asf
> > > >>
> > > >> On Mon, Jan 29, 2018 at 11:34 AM, Joe Witt <joe.witt@gmail.com>
> > wrote:
> > > >> > Mark
> > > >> >
> > > >> > Thanks for brining this up.  I do agree.
> > > >> >
> > > >> > We need to probably provide more description on the contributor
> > guide
> > > >> > or elsewhere of which aspects makes PRs easier to commit:
> > > >> >  - They have unit tests which cover core capabilities but if
> they're
> > > >> > cloud service dependent or highly network/disk oriented they
have
> > > >> > integration tests instead of unit tests for the high risk or
> > > >> > environmentally sensitive bits.
> > > >> >  - They have *thoroughly* reviewed and covered License and Notice
> > > >> > updates and are done consistently with the L&N of the rest
of the
> > > >> > project.
> > > >> >  - They pass all checks on Travis-CI
> > > >> >  - If they required manual integration tests that detailed
> > > >> > instructions/explanations of external system setup and
> configuration
> > > >> > and test processes is provided.
> > > >> >
> > > >> > And maybe some explanation of which items are very difficult
to
> get
> > > >> > good reviewer help on:
> > > >> > - Things which integrate with external systems that are not easily
> > > >> > replicated for testing.  Consider whiz-bang database StoreIt.
 If
> we
> > > >> > dont have others aware of or famiilar with the StoreIt system
it
> is
> > > >> > really tough to find a good reviewer and timely response.
> > > >> >
> > > >> > We also need to revisit this as we progress an extension registry
> > > >> mechanism.
> > > >> >
> > > >> > Thanks
> > > >> >
> > > >> > On Mon, Jan 29, 2018 at 11:29 AM, Mark Payne <
> markap14@hotmail.com>
> > > >> 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
> > > >>
> > >
> >
>

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