Thanks Joe.
On Fri, Jul 7, 2017 at 11:38 PM, Joe Witt wrote:
> Andrew
>
> You should now have permissions to edit the wiki.
>
> Thanks
> Joe
>
> On Fri, Jul 7, 2017 at 11:34 PM, Andrew Psaltis
> wrote:
> > Hi,
> > I am interested in fixing an issue
Andrew
You should now have permissions to edit the wiki.
Thanks
Joe
On Fri, Jul 7, 2017 at 11:34 PM, Andrew Psaltis
wrote:
> Hi,
> I am interested in fixing an issue and adding more content in the
> contributor guide on the wiki. One change is pretty simple an invalid
Hi,
I am interested in fixing an issue and adding more content in the
contributor guide on the wiki. One change is pretty simple an invalid URL.
The additional content I am thinking of at this time is around this process
in particular. I searched around trying to understand the process of how to
I was just about to respond to myself, thanks Aldrin!
For anyone else searching just add this to the pom
org.apache.rat
apache-rat-plugin
src/test/resources/*.json
Regards,
Chris
> On Jul 7, 2017, at 4:06
You can provide exclusions for files such as this in the pom.xml. Don't
have specific path handy as on mobile but some grep'ing of other .json file
names should show the way.
On Fri, Jul 7, 2017 at 14:03 Chris Herrera
wrote:
> Hi All,
>
> I am working on a
Hi All,
I am working on a contribution, and as part of it, there is a json file. I
cannot put comments in that json file and, as such, it does not pass the rat
check. Has anyone dealt with this issue before?
Regards,
Chris
I am in favor of allowing Scenario A and leaving it up to the committer /
submitter to determine if the review is sufficient to merge or if an additional
review(s) should take place.
I think for committers will know the difference between, say, a documentation
update or minor enhancement / fix
I submitted a pull request for running MiNiFi as a Windows service using
Commons Daemon's Procrun. Like winsw it supports more than just Java
applications so it should work for the C++ version as well. I went with it
due to it also being ASL and just due to personal familiarity. If there's a
Joe(s), as you mentioned, even if we have a non-committer review, it can’t be
merged until a committer decides whether to accept whatever decision was
provided. So, the burden is still on committers as to whether it’s really a +1
or not. And presumably this should only happen if there’s some
thanks team. board report submitted.
On Fri, Jul 7, 2017 at 10:05 AM, Yolanda Davis
wrote:
> +1 LGTM
>
> On Fri, Jul 7, 2017 at 8:10 AM, Marc wrote:
>
>> +1 Looks good!
>>
>> On Fri, Jul 7, 2017 at 7:43 AM, Andrew Psaltis
Chris,
This sounds great! IMO Realistic data generation in all forms is a great
addition, looking forward to your contribution!
Regards,
Matt
> On Jul 7, 2017, at 10:18 AM, Chris Herrera wrote:
>
> Hi All,
>
> I am trying to gauge interest in a processor I have
Hi All,
I am trying to gauge interest in a processor I have written that generates
realistic time series data. I used the excellent GenerateFlowFile processor for
a long time for load testing, etc..., however, I needed something that mirrored
more the semantics of a sensor, and more
We're looking at a possible set of scenarios comprised of a
'submitter' and a 'reviewer'. There can be one or more reviewers. A
submitter or reviewer is either a committer or is not a committer. If
there is at least one reviewer that is a committer it is a committer
reviewed scenario. So with
+1 LGTM
On Fri, Jul 7, 2017 at 8:10 AM, Marc wrote:
> +1 Looks good!
>
> On Fri, Jul 7, 2017 at 7:43 AM, Andrew Psaltis
> wrote:
>
> > +1
> >
> > On Thu, Jul 6, 2017 at 08:20 Pierre Villard >
> > wrote:
> >
> > > +1
I agree that non-committer review make more sense if the reviewer has
established some level of credibility and involvement in the community.
Ultimately, the final committer has to be a community member and they will
have final responsibility for the code being Apache compliant and NiFi
ready, so
There are always exceptions, but I think the best way to ensure that the
spirit of what we're going for is being followed is to say "no one commits
their own code". While additional eyes are never going to be a bad thing,
requiring a second person to "sign off" on and then commit the code would
I agree with encouraging reviews from everyone, but I lean towards
"binding" reviews coming from committers.
If we allow any review to be binding, there could be completely
different levels of review that occur...
There could be someone who isn't a committer yet, but has been
contributing
+1 LGTM, thank you for putting this together!
Regards,
Matt
On Tue, Jul 4, 2017 at 11:50 AM, Joe Witt wrote:
> Team,
>
> It's that time again to submit our board report for Apache NiFi.
> Please see below draft. If you have any suggestions/fixes, edits
> please advise.
>
>
+1 Looks good!
On Fri, Jul 7, 2017 at 7:43 AM, Andrew Psaltis
wrote:
> +1
>
> On Thu, Jul 6, 2017 at 08:20 Pierre Villard
> wrote:
>
> > +1
> >
> > 2017-07-06 14:09 GMT+02:00 Joe Skora :
> >
> > > +1 Release this package
+1
On Thu, Jul 6, 2017 at 08:20 Pierre Villard
wrote:
> +1
>
> 2017-07-06 14:09 GMT+02:00 Joe Skora :
>
> > +1 Release this package as NiFi Board Report July 2017
> >
> > On Thu, Jul 6, 2017 at 7:46 AM, Tony Kurc wrote:
> >
> >
Thanks for fielding the question, Tony.
Joe and James' statements both make sense. I suppose a case by case
analysis could be carried out, too. For example, since I'm mostly
unfamiliar with the code base but am looking to gain familiarity, I'm
reviewing pretty straightforward or trivial PRs. My
21 matches
Mail list logo