Re: Establishment of MiNiFi repo and supporting tools
Excellent, thanks! > On Mar 14, 2016, at 4:57 PM, Aldrin Piri wrote: > > Given the positive response, I have submitted requests for both a new JIRA > and new Git repository which INFRA has kindly stood up for us. MiNiFi JIRA > and Git are available at [1] and [2], respectively. > > [1] https://issues.apache.org/jira/browse/MINIFI/ > [2] https://git-wip-us.apache.org/repos/asf/nifi-minifi.git > > On Fri, Mar 11, 2016 at 1:45 PM, Andy LoPresto > wrote: > >> +1. >> >> Andy LoPresto >> alopresto.apa...@gmail.com >> PGP Fingerprint: 70EC B3E5 98A6 5A3F D3C4 BACE 3C6E F65B 2F7D EF69 >> >> On Mar 11, 2016, at 9:41 AM, Mark Payne wrote: >> >> +1 from me as well >> >> On Mar 11, 2016, at 8:36 AM, Matt Burgess wrote: >> >> I'm a +1 as well. >> >> On Mar 11, 2016, at 8:26 AM, Tony Kurc wrote: >> >> Should this be marked as a [VOTE]? In any case, I'm +1 >> >> On Fri, Mar 11, 2016 at 1:11 AM, Aldrin Piri wrote: >> >> All, >> >> Didn't explicitly mention this, but was aiming for a lazy consensus [1] to >> continuing on with the outlined procedure. If no one objects in the next >> two days, will look at carrying out the prescribed items listed. >> >> >> [1] http://www.apache.org/foundation/voting.html#LazyConsensus >> >> On Wed, Mar 9, 2016 at 3:28 PM, Aldrin Piri wrote: >> >> NiFi Community, >> >> Originally discussed in January [1], the MiNiFi agent model was met with >> positive feedback. I would like to propose a concerted effort toward the >> execution on the ideas presented and establish a basis for incorporation >> >> of >> >> the feedback received from, and collaboration with, the community to move >> toward our goals of helping with dataflow from the point of its origin. >> >> To that end, I would like to propose the creation of: >> >> - >> >> a separate repository (nifi-minifi), >> - >> >> establishment of a MiNiFi JIRA (MINIFI), and >> - >> >> production of an associated feature proposals and design documentation >> within our Confluence Wiki spaces beyond the initial points outlined >> >> by Joe >> >> with some additional proposals architecture and roadmap >> >> The separate JIRA and Git repo map to the existing ASF infrastructure for >> projects with similar efforts and will aid in a cleaner release and issue >> management process. >> >> Central to the aims of MiNiFi, the tenets of its operation and execution >> of dataflow are the same as NiFi itself: security, provenance, and >> management of dataflow; helping bring information to NiFi while >> >> maintaining >> >> the full extent of its provenance. >> >> Some clarifying points based on the discussion that existed previously: >> >> - >> >> While there may be reuse of NiFi components and some overlap, MiNiFi >> is a separate effort that is complementary to but not necessarily >> >> directly >> >> compatible with existing components and extensions. Obviously there >> >> has >> >> been a lot of great effort which we can reuse, but in striving to be a >> smaller footprint, we should not find ourselves beholden to the >> >> existing, >> >> core, NiFi architecture. >> - >> >> There will exist scenarios where there is an inherent need to go >> smaller and closer to the source system. This will take the form of >> >> native >> >> code that builds upon the same efforts and items originally developed >> >> under >> >> the Java ecosystem. >> - >> >> Design should take consideration of disparate execution environments >> and provide ways to robustly handle varying means of communication and >> exchange. Accordingly, communications both in management of agents >> >> and the >> >> transference of data should be neutral to technologies, providing the >> >> same >> >> flexibility and adaptation that allows NiFi to communicate with a wide >> breadth of systems, protocols, schemas, and formats. >> >> >> [1] >> >> >> http://apache-nifi-developer-list.39713.n7.nabble.com/DISCUSS-Proposal-for-an-Apache-NiFi-sub-project-MiNiFi-td6141.html >> >> >> >>
Re: Establishment of MiNiFi repo and supporting tools
Given the positive response, I have submitted requests for both a new JIRA and new Git repository which INFRA has kindly stood up for us. MiNiFi JIRA and Git are available at [1] and [2], respectively. [1] https://issues.apache.org/jira/browse/MINIFI/ [2] https://git-wip-us.apache.org/repos/asf/nifi-minifi.git On Fri, Mar 11, 2016 at 1:45 PM, Andy LoPresto wrote: > +1. > > Andy LoPresto > alopresto.apa...@gmail.com > PGP Fingerprint: 70EC B3E5 98A6 5A3F D3C4 BACE 3C6E F65B 2F7D EF69 > > On Mar 11, 2016, at 9:41 AM, Mark Payne wrote: > > +1 from me as well > > On Mar 11, 2016, at 8:36 AM, Matt Burgess wrote: > > I'm a +1 as well. > > On Mar 11, 2016, at 8:26 AM, Tony Kurc wrote: > > Should this be marked as a [VOTE]? In any case, I'm +1 > > On Fri, Mar 11, 2016 at 1:11 AM, Aldrin Piri wrote: > > All, > > Didn't explicitly mention this, but was aiming for a lazy consensus [1] to > continuing on with the outlined procedure. If no one objects in the next > two days, will look at carrying out the prescribed items listed. > > > [1] http://www.apache.org/foundation/voting.html#LazyConsensus > > On Wed, Mar 9, 2016 at 3:28 PM, Aldrin Piri wrote: > > NiFi Community, > > Originally discussed in January [1], the MiNiFi agent model was met with > positive feedback. I would like to propose a concerted effort toward the > execution on the ideas presented and establish a basis for incorporation > > of > > the feedback received from, and collaboration with, the community to move > toward our goals of helping with dataflow from the point of its origin. > > To that end, I would like to propose the creation of: > > - > > a separate repository (nifi-minifi), > - > > establishment of a MiNiFi JIRA (MINIFI), and > - > > production of an associated feature proposals and design documentation > within our Confluence Wiki spaces beyond the initial points outlined > > by Joe > > with some additional proposals architecture and roadmap > > The separate JIRA and Git repo map to the existing ASF infrastructure for > projects with similar efforts and will aid in a cleaner release and issue > management process. > > Central to the aims of MiNiFi, the tenets of its operation and execution > of dataflow are the same as NiFi itself: security, provenance, and > management of dataflow; helping bring information to NiFi while > > maintaining > > the full extent of its provenance. > > Some clarifying points based on the discussion that existed previously: > > - > > While there may be reuse of NiFi components and some overlap, MiNiFi > is a separate effort that is complementary to but not necessarily > > directly > > compatible with existing components and extensions. Obviously there > > has > > been a lot of great effort which we can reuse, but in striving to be a > smaller footprint, we should not find ourselves beholden to the > > existing, > > core, NiFi architecture. > - > > There will exist scenarios where there is an inherent need to go > smaller and closer to the source system. This will take the form of > > native > > code that builds upon the same efforts and items originally developed > > under > > the Java ecosystem. > - > > Design should take consideration of disparate execution environments > and provide ways to robustly handle varying means of communication and > exchange. Accordingly, communications both in management of agents > > and the > > transference of data should be neutral to technologies, providing the > > same > > flexibility and adaptation that allows NiFi to communicate with a wide > breadth of systems, protocols, schemas, and formats. > > > [1] > > > http://apache-nifi-developer-list.39713.n7.nabble.com/DISCUSS-Proposal-for-an-Apache-NiFi-sub-project-MiNiFi-td6141.html > > > >
Re: Establishment of MiNiFi repo and supporting tools
+1. Andy LoPresto alopresto.apa...@gmail.com PGP Fingerprint: 70EC B3E5 98A6 5A3F D3C4 BACE 3C6E F65B 2F7D EF69 > On Mar 11, 2016, at 9:41 AM, Mark Payne wrote: > > +1 from me as well > >> On Mar 11, 2016, at 8:36 AM, Matt Burgess wrote: >> >> I'm a +1 as well. >> >>> On Mar 11, 2016, at 8:26 AM, Tony Kurc wrote: >>> >>> Should this be marked as a [VOTE]? In any case, I'm +1 >>> On Fri, Mar 11, 2016 at 1:11 AM, Aldrin Piri wrote: All, Didn't explicitly mention this, but was aiming for a lazy consensus [1] to continuing on with the outlined procedure. If no one objects in the next two days, will look at carrying out the prescribed items listed. [1] http://www.apache.org/foundation/voting.html#LazyConsensus > On Wed, Mar 9, 2016 at 3:28 PM, Aldrin Piri wrote: > > NiFi Community, > > Originally discussed in January [1], the MiNiFi agent model was met with > positive feedback. I would like to propose a concerted effort toward the > execution on the ideas presented and establish a basis for incorporation of > the feedback received from, and collaboration with, the community to move > toward our goals of helping with dataflow from the point of its origin. > > To that end, I would like to propose the creation of: > > - > > a separate repository (nifi-minifi), > - > > establishment of a MiNiFi JIRA (MINIFI), and > - > > production of an associated feature proposals and design documentation > within our Confluence Wiki spaces beyond the initial points outlined by Joe > with some additional proposals architecture and roadmap > > The separate JIRA and Git repo map to the existing ASF infrastructure for > projects with similar efforts and will aid in a cleaner release and issue > management process. > > Central to the aims of MiNiFi, the tenets of its operation and execution > of dataflow are the same as NiFi itself: security, provenance, and > management of dataflow; helping bring information to NiFi while maintaining > the full extent of its provenance. > > Some clarifying points based on the discussion that existed previously: > > - > > While there may be reuse of NiFi components and some overlap, MiNiFi > is a separate effort that is complementary to but not necessarily directly > compatible with existing components and extensions. Obviously there has > been a lot of great effort which we can reuse, but in striving to be a > smaller footprint, we should not find ourselves beholden to the existing, > core, NiFi architecture. > - > > There will exist scenarios where there is an inherent need to go > smaller and closer to the source system. This will take the form of native > code that builds upon the same efforts and items originally developed under > the Java ecosystem. > - > > Design should take consideration of disparate execution environments > and provide ways to robustly handle varying means of communication and > exchange. Accordingly, communications both in management of agents and the > transference of data should be neutral to technologies, providing the same > flexibility and adaptation that allows NiFi to communicate with a wide > breadth of systems, protocols, schemas, and formats. > > > [1] http://apache-nifi-developer-list.39713.n7.nabble.com/DISCUSS-Proposal-for-an-Apache-NiFi-sub-project-MiNiFi-td6141.html > signature.asc Description: Message signed with OpenPGP using GPGMail
Re: Establishment of MiNiFi repo and supporting tools
+1 from me as well > On Mar 11, 2016, at 8:36 AM, Matt Burgess wrote: > > I'm a +1 as well. > >> On Mar 11, 2016, at 8:26 AM, Tony Kurc wrote: >> >> Should this be marked as a [VOTE]? In any case, I'm +1 >> >>> On Fri, Mar 11, 2016 at 1:11 AM, Aldrin Piri wrote: >>> >>> All, >>> >>> Didn't explicitly mention this, but was aiming for a lazy consensus [1] to >>> continuing on with the outlined procedure. If no one objects in the next >>> two days, will look at carrying out the prescribed items listed. >>> >>> >>> [1] http://www.apache.org/foundation/voting.html#LazyConsensus >>> On Wed, Mar 9, 2016 at 3:28 PM, Aldrin Piri wrote: NiFi Community, Originally discussed in January [1], the MiNiFi agent model was met with positive feedback. I would like to propose a concerted effort toward the execution on the ideas presented and establish a basis for incorporation >>> of the feedback received from, and collaboration with, the community to move toward our goals of helping with dataflow from the point of its origin. To that end, I would like to propose the creation of: - a separate repository (nifi-minifi), - establishment of a MiNiFi JIRA (MINIFI), and - production of an associated feature proposals and design documentation within our Confluence Wiki spaces beyond the initial points outlined >>> by Joe with some additional proposals architecture and roadmap The separate JIRA and Git repo map to the existing ASF infrastructure for projects with similar efforts and will aid in a cleaner release and issue management process. Central to the aims of MiNiFi, the tenets of its operation and execution of dataflow are the same as NiFi itself: security, provenance, and management of dataflow; helping bring information to NiFi while >>> maintaining the full extent of its provenance. Some clarifying points based on the discussion that existed previously: - While there may be reuse of NiFi components and some overlap, MiNiFi is a separate effort that is complementary to but not necessarily >>> directly compatible with existing components and extensions. Obviously there >>> has been a lot of great effort which we can reuse, but in striving to be a smaller footprint, we should not find ourselves beholden to the >>> existing, core, NiFi architecture. - There will exist scenarios where there is an inherent need to go smaller and closer to the source system. This will take the form of >>> native code that builds upon the same efforts and items originally developed >>> under the Java ecosystem. - Design should take consideration of disparate execution environments and provide ways to robustly handle varying means of communication and exchange. Accordingly, communications both in management of agents >>> and the transference of data should be neutral to technologies, providing the >>> same flexibility and adaptation that allows NiFi to communicate with a wide breadth of systems, protocols, schemas, and formats. [1] >>> http://apache-nifi-developer-list.39713.n7.nabble.com/DISCUSS-Proposal-for-an-Apache-NiFi-sub-project-MiNiFi-td6141.html >>>
Re: Establishment of MiNiFi repo and supporting tools
I'm a +1 as well. > On Mar 11, 2016, at 8:26 AM, Tony Kurc wrote: > > Should this be marked as a [VOTE]? In any case, I'm +1 > >> On Fri, Mar 11, 2016 at 1:11 AM, Aldrin Piri wrote: >> >> All, >> >> Didn't explicitly mention this, but was aiming for a lazy consensus [1] to >> continuing on with the outlined procedure. If no one objects in the next >> two days, will look at carrying out the prescribed items listed. >> >> >> [1] http://www.apache.org/foundation/voting.html#LazyConsensus >> >>> On Wed, Mar 9, 2016 at 3:28 PM, Aldrin Piri wrote: >>> >>> NiFi Community, >>> >>> Originally discussed in January [1], the MiNiFi agent model was met with >>> positive feedback. I would like to propose a concerted effort toward the >>> execution on the ideas presented and establish a basis for incorporation >> of >>> the feedback received from, and collaboration with, the community to move >>> toward our goals of helping with dataflow from the point of its origin. >>> >>> To that end, I would like to propose the creation of: >>> >>> - >>> >>> a separate repository (nifi-minifi), >>> - >>> >>> establishment of a MiNiFi JIRA (MINIFI), and >>> - >>> >>> production of an associated feature proposals and design documentation >>> within our Confluence Wiki spaces beyond the initial points outlined >> by Joe >>> with some additional proposals architecture and roadmap >>> >>> The separate JIRA and Git repo map to the existing ASF infrastructure for >>> projects with similar efforts and will aid in a cleaner release and issue >>> management process. >>> >>> Central to the aims of MiNiFi, the tenets of its operation and execution >>> of dataflow are the same as NiFi itself: security, provenance, and >>> management of dataflow; helping bring information to NiFi while >> maintaining >>> the full extent of its provenance. >>> >>> Some clarifying points based on the discussion that existed previously: >>> >>> - >>> >>> While there may be reuse of NiFi components and some overlap, MiNiFi >>> is a separate effort that is complementary to but not necessarily >> directly >>> compatible with existing components and extensions. Obviously there >> has >>> been a lot of great effort which we can reuse, but in striving to be a >>> smaller footprint, we should not find ourselves beholden to the >> existing, >>> core, NiFi architecture. >>> - >>> >>> There will exist scenarios where there is an inherent need to go >>> smaller and closer to the source system. This will take the form of >> native >>> code that builds upon the same efforts and items originally developed >> under >>> the Java ecosystem. >>> - >>> >>> Design should take consideration of disparate execution environments >>> and provide ways to robustly handle varying means of communication and >>> exchange. Accordingly, communications both in management of agents >> and the >>> transference of data should be neutral to technologies, providing the >> same >>> flexibility and adaptation that allows NiFi to communicate with a wide >>> breadth of systems, protocols, schemas, and formats. >>> >>> >>> [1] >> http://apache-nifi-developer-list.39713.n7.nabble.com/DISCUSS-Proposal-for-an-Apache-NiFi-sub-project-MiNiFi-td6141.html >>
Re: Establishment of MiNiFi repo and supporting tools
Should this be marked as a [VOTE]? In any case, I'm +1 On Fri, Mar 11, 2016 at 1:11 AM, Aldrin Piri wrote: > All, > > Didn't explicitly mention this, but was aiming for a lazy consensus [1] to > continuing on with the outlined procedure. If no one objects in the next > two days, will look at carrying out the prescribed items listed. > > > [1] http://www.apache.org/foundation/voting.html#LazyConsensus > > On Wed, Mar 9, 2016 at 3:28 PM, Aldrin Piri wrote: > > > NiFi Community, > > > > Originally discussed in January [1], the MiNiFi agent model was met with > > positive feedback. I would like to propose a concerted effort toward the > > execution on the ideas presented and establish a basis for incorporation > of > > the feedback received from, and collaboration with, the community to move > > toward our goals of helping with dataflow from the point of its origin. > > > > To that end, I would like to propose the creation of: > > > >- > > > >a separate repository (nifi-minifi), > >- > > > >establishment of a MiNiFi JIRA (MINIFI), and > >- > > > >production of an associated feature proposals and design documentation > >within our Confluence Wiki spaces beyond the initial points outlined > by Joe > >with some additional proposals architecture and roadmap > > > > The separate JIRA and Git repo map to the existing ASF infrastructure for > > projects with similar efforts and will aid in a cleaner release and issue > > management process. > > > > Central to the aims of MiNiFi, the tenets of its operation and execution > > of dataflow are the same as NiFi itself: security, provenance, and > > management of dataflow; helping bring information to NiFi while > maintaining > > the full extent of its provenance. > > > > Some clarifying points based on the discussion that existed previously: > > > >- > > > >While there may be reuse of NiFi components and some overlap, MiNiFi > >is a separate effort that is complementary to but not necessarily > directly > >compatible with existing components and extensions. Obviously there > has > >been a lot of great effort which we can reuse, but in striving to be a > >smaller footprint, we should not find ourselves beholden to the > existing, > >core, NiFi architecture. > >- > > > >There will exist scenarios where there is an inherent need to go > >smaller and closer to the source system. This will take the form of > native > >code that builds upon the same efforts and items originally developed > under > >the Java ecosystem. > >- > > > >Design should take consideration of disparate execution environments > >and provide ways to robustly handle varying means of communication and > >exchange. Accordingly, communications both in management of agents > and the > >transference of data should be neutral to technologies, providing the > same > >flexibility and adaptation that allows NiFi to communicate with a wide > >breadth of systems, protocols, schemas, and formats. > > > > > > [1] > > > http://apache-nifi-developer-list.39713.n7.nabble.com/DISCUSS-Proposal-for-an-Apache-NiFi-sub-project-MiNiFi-td6141.html > > >
Re: Establishment of MiNiFi repo and supporting tools
All, Didn't explicitly mention this, but was aiming for a lazy consensus [1] to continuing on with the outlined procedure. If no one objects in the next two days, will look at carrying out the prescribed items listed. [1] http://www.apache.org/foundation/voting.html#LazyConsensus On Wed, Mar 9, 2016 at 3:28 PM, Aldrin Piri wrote: > NiFi Community, > > Originally discussed in January [1], the MiNiFi agent model was met with > positive feedback. I would like to propose a concerted effort toward the > execution on the ideas presented and establish a basis for incorporation of > the feedback received from, and collaboration with, the community to move > toward our goals of helping with dataflow from the point of its origin. > > To that end, I would like to propose the creation of: > >- > >a separate repository (nifi-minifi), >- > >establishment of a MiNiFi JIRA (MINIFI), and >- > >production of an associated feature proposals and design documentation >within our Confluence Wiki spaces beyond the initial points outlined by Joe >with some additional proposals architecture and roadmap > > The separate JIRA and Git repo map to the existing ASF infrastructure for > projects with similar efforts and will aid in a cleaner release and issue > management process. > > Central to the aims of MiNiFi, the tenets of its operation and execution > of dataflow are the same as NiFi itself: security, provenance, and > management of dataflow; helping bring information to NiFi while maintaining > the full extent of its provenance. > > Some clarifying points based on the discussion that existed previously: > >- > >While there may be reuse of NiFi components and some overlap, MiNiFi >is a separate effort that is complementary to but not necessarily directly >compatible with existing components and extensions. Obviously there has >been a lot of great effort which we can reuse, but in striving to be a >smaller footprint, we should not find ourselves beholden to the existing, >core, NiFi architecture. >- > >There will exist scenarios where there is an inherent need to go >smaller and closer to the source system. This will take the form of native >code that builds upon the same efforts and items originally developed under >the Java ecosystem. >- > >Design should take consideration of disparate execution environments >and provide ways to robustly handle varying means of communication and >exchange. Accordingly, communications both in management of agents and the >transference of data should be neutral to technologies, providing the same >flexibility and adaptation that allows NiFi to communicate with a wide >breadth of systems, protocols, schemas, and formats. > > > [1] > http://apache-nifi-developer-list.39713.n7.nabble.com/DISCUSS-Proposal-for-an-Apache-NiFi-sub-project-MiNiFi-td6141.html >
