Re: [DISCUSS] Addressing Lingering Pull Requests

2018-01-29 Thread James Wing
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 "c

Re: Programmatically adding processors

2018-01-29 Thread Phil H
Thanks Robert! Cheers, Phil > On 30 Jan 2018, at 13:35, Robert R. Bruno wrote: > > In the past, I've used the Chrome developer tools network view to see the > api calls made by the NiFi UI. Just manually go through the steps you want > to automate in the UI and view the REST calls made. > > H

Re: Programmatically adding processors

2018-01-29 Thread Robert R. Bruno
In the past, I've used the Chrome developer tools network view to see the api calls made by the NiFi UI. Just manually go through the steps you want to automate in the UI and view the REST calls made. Hope that helps. Robert On Mon, Jan 29, 2018, 21:31 Phil H wrote: > Hi there, > > I need to

Programmatically adding processors

2018-01-29 Thread Phil H
Hi there, I need to add new properties/routes to RouteOnAttribute and subsequent PutFile processors based on an external input (a basic web interface). Hoping someone can point me in the right direction in terms of either config files to change, or API calls to make to simulate what the NiFi U

Re: [DISCUSS] Addressing Lingering Pull Requests

2018-01-29 Thread Sivaprasanna
Thanks. I’ll take a look. On Tue, 30 Jan 2018 at 7:49 AM, Aldrin Piri 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, 2

Re: [DISCUSS] Addressing Lingering Pull Requests

2018-01-29 Thread Aldrin Piri
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 wrote: > Apologies. I’m very new to contributing so I’m not a

Re: [DISCUSS] Addressing Lingering Pull Requests

2018-01-29 Thread Sivaprasanna
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 wrote: > Agree with everything being said here. We clearly

Re: [DISCUSS] Addressing Lingering Pull Requests

2018-01-29 Thread Pierre Villard
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

Bulletins on Processors summary tab

2018-01-29 Thread Mark Bean
In NiFi 0.x, the Summary/Processors page lists bulletins (if any) in the first column along with 'info'. This is a convenient way to sort the list of processors and find those with active bulletins. However, in 1.x, this feature seems to be missing on the Summary/Processors tab. Is there some othe

Re: [DISCUSS] Addressing Lingering Pull Requests

2018-01-29 Thread Joe Witt
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 wrote: > Gitbox was favorably received when we discussed it prior: > https://lists.apache.org/thread.html/de5e103994f356b1b8a572410938eef44af8cb352210e35305c04b

Re: [DISCUSS] Addressing Lingering Pull Requests

2018-01-29 Thread Aldrin Piri
Gitbox was favorably received when we discussed it prior: https://lists.apache.org/thread.html/de5e103994f356b1b8a572410938eef44af8cb352210e35305c04bc9@%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. --aldr

Re: [DISCUSS] Addressing Lingering Pull Requests

2018-01-29 Thread Bryan Bende
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 d

Re: [DISCUSS] Addressing Lingering Pull Requests

2018-01-29 Thread Joe Witt
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 oriente

[DISCUSS] Addressing Lingering Pull Requests

2018-01-29 Thread Mark Payne
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 shoul