Thanks. I’ll take a look. On Tue, 30 Jan 2018 at 7:49 AM, Aldrin Piri <[email protected]> wrote:
> 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 <[email protected]> > 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 < > > [email protected]> > > 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 <[email protected]>: > > > > > > > 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 <[email protected]> > > > > 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 <[email protected]> > > > 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 <[email protected]> > > > 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 < > > [email protected]> > > > > >> 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 > > > > >> > > > > > > > > > >
