"Meta" contributions and files

classic Classic list List threaded Threaded
5 messages Options
Reply | Threaded
Open this post in threaded view
|

"Meta" contributions and files

Aldrin Piri
What is the right destination for handling, for lack of better phrasing
meta-source/contributions?

This was broached briefly with the site design, but that found a home,
appropriately with the main repository at the top level.  With the talk of
configuration for editors as we strive towards a consistent code style and
some work I've been doing with Docker to support NiFi, where do these items
reside?

Based on my experiences and what I have witnessed on other projects, a
contrib folder in the repository seems to be how this is classically
handled; you do not need these items, but they may be helpful.  Seems like
an appropriate fit, with some subdirectories that group these by intent to
avoid it becoming a dumping ground.  Any additional thoughts or suggestions
on how we can best incorporate these in a sane and organized fashion?
Reply | Threaded
Open this post in threaded view
|

Re: "Meta" contributions and files

Joe Witt
Aldrin,

Mark made a spark receive during this last build cycle.  It is under
root/nifi/nifi-externals.  Would this cover your case or are you
thinking more broadly?

In the case of docker i suspect that gets blurry with the lines of
binary release vs source release.  What in your view would need to
live in our source for docker support?

Thanks
Joe

On Sat, Mar 21, 2015 at 1:54 PM, Aldrin Piri <[hidden email]> wrote:

> What is the right destination for handling, for lack of better phrasing
> meta-source/contributions?
>
> This was broached briefly with the site design, but that found a home,
> appropriately with the main repository at the top level.  With the talk of
> configuration for editors as we strive towards a consistent code style and
> some work I've been doing with Docker to support NiFi, where do these items
> reside?
>
> Based on my experiences and what I have witnessed on other projects, a
> contrib folder in the repository seems to be how this is classically
> handled; you do not need these items, but they may be helpful.  Seems like
> an appropriate fit, with some subdirectories that group these by intent to
> avoid it becoming a dumping ground.  Any additional thoughts or suggestions
> on how we can best incorporate these in a sane and organized fashion?
Reply | Threaded
Open this post in threaded view
|

Re: "Meta" contributions and files

Aldrin Piri
At first reaction, I think this goes a broader than that use case.  These
items aren't necessarily used with NiFi, but in support of it.  I could
probably go either way though.

The Docker items, as I see them, would not be binary images, there are
other avenues for that.  This is largely in support of NiFi-153 and is
completely source driven.  The work I have done thus far is simply a
Dockerfile, an initialization script, and a Makefile; all source files, no
binaries (although the Makefile will retrieve a NiFi release when invoked).

On Sat, Mar 21, 2015 at 2:00 PM, Joe Witt <[hidden email]> wrote:

> Aldrin,
>
> Mark made a spark receive during this last build cycle.  It is under
> root/nifi/nifi-externals.  Would this cover your case or are you
> thinking more broadly?
>
> In the case of docker i suspect that gets blurry with the lines of
> binary release vs source release.  What in your view would need to
> live in our source for docker support?
>
> Thanks
> Joe
>
> On Sat, Mar 21, 2015 at 1:54 PM, Aldrin Piri <[hidden email]> wrote:
> > What is the right destination for handling, for lack of better phrasing
> > meta-source/contributions?
> >
> > This was broached briefly with the site design, but that found a home,
> > appropriately with the main repository at the top level.  With the talk
> of
> > configuration for editors as we strive towards a consistent code style
> and
> > some work I've been doing with Docker to support NiFi, where do these
> items
> > reside?
> >
> > Based on my experiences and what I have witnessed on other projects, a
> > contrib folder in the repository seems to be how this is classically
> > handled; you do not need these items, but they may be helpful.  Seems
> like
> > an appropriate fit, with some subdirectories that group these by intent
> to
> > avoid it becoming a dumping ground.  Any additional thoughts or
> suggestions
> > on how we can best incorporate these in a sane and organized fashion?
>
Reply | Threaded
Open this post in threaded view
|

Re: "Meta" contributions and files

Joe Witt
Ah ok understood.  Still though I wonder if that might not be a good
path to take.  I say that because by being in the source tree it gets
'released' officially as part of the 'nifi' source release.  That
bundle then is published to approved ASF locations and is properly
licensed/etc.. Folks are aware of the rules of use and so on.  I do
get what you're saying though.  Don't have the answer.

There has to be some good examples of what other apache projects have
done.  Have you done any searches for examples there?  I'm thinking
aurora or mesos ?

On Sat, Mar 21, 2015 at 2:04 PM, Aldrin Piri <[hidden email]> wrote:

> At first reaction, I think this goes a broader than that use case.  These
> items aren't necessarily used with NiFi, but in support of it.  I could
> probably go either way though.
>
> The Docker items, as I see them, would not be binary images, there are
> other avenues for that.  This is largely in support of NiFi-153 and is
> completely source driven.  The work I have done thus far is simply a
> Dockerfile, an initialization script, and a Makefile; all source files, no
> binaries (although the Makefile will retrieve a NiFi release when invoked).
>
> On Sat, Mar 21, 2015 at 2:00 PM, Joe Witt <[hidden email]> wrote:
>
>> Aldrin,
>>
>> Mark made a spark receive during this last build cycle.  It is under
>> root/nifi/nifi-externals.  Would this cover your case or are you
>> thinking more broadly?
>>
>> In the case of docker i suspect that gets blurry with the lines of
>> binary release vs source release.  What in your view would need to
>> live in our source for docker support?
>>
>> Thanks
>> Joe
>>
>> On Sat, Mar 21, 2015 at 1:54 PM, Aldrin Piri <[hidden email]> wrote:
>> > What is the right destination for handling, for lack of better phrasing
>> > meta-source/contributions?
>> >
>> > This was broached briefly with the site design, but that found a home,
>> > appropriately with the main repository at the top level.  With the talk
>> of
>> > configuration for editors as we strive towards a consistent code style
>> and
>> > some work I've been doing with Docker to support NiFi, where do these
>> items
>> > reside?
>> >
>> > Based on my experiences and what I have witnessed on other projects, a
>> > contrib folder in the repository seems to be how this is classically
>> > handled; you do not need these items, but they may be helpful.  Seems
>> like
>> > an appropriate fit, with some subdirectories that group these by intent
>> to
>> > avoid it becoming a dumping ground.  Any additional thoughts or
>> suggestions
>> > on how we can best incorporate these in a sane and organized fashion?
>>
Reply | Threaded
Open this post in threaded view
|

Re: "Meta" contributions and files

Aldrin Piri
Well, there isn't anything overly consistent, but here are some examples I
found that provide similar utilities and files.

Accumulo has a contrib folder that they actually store style configuration
files [1].

Aurora includes Vagrant files in the root of the repo [2].

Spark has a docker folder [3] as well as an external folder.

Mesos has a support folder used for operations in handling releases and
style [4] and a Dockerfile in the source root

Thrift has a contrib folder [5].

Stratos has a tools folder [6].

[1] https://github.com/apache/accumulo
[2] https://github.com/apache/incubator-aurora
[3] https://github.com/apache/spark/tree/master/docker
[4] https://github.com/apache/mesos/tree/master/support
[5] https://github.com/apache/thrift/tree/master/contrib
[6] https://github.com/apache/stratos/tree/master/tools

On Sat, Mar 21, 2015 at 2:11 PM, Joe Witt <[hidden email]> wrote:

> Ah ok understood.  Still though I wonder if that might not be a good
> path to take.  I say that because by being in the source tree it gets
> 'released' officially as part of the 'nifi' source release.  That
> bundle then is published to approved ASF locations and is properly
> licensed/etc.. Folks are aware of the rules of use and so on.  I do
> get what you're saying though.  Don't have the answer.
>
> There has to be some good examples of what other apache projects have
> done.  Have you done any searches for examples there?  I'm thinking
> aurora or mesos ?
>
> On Sat, Mar 21, 2015 at 2:04 PM, Aldrin Piri <[hidden email]> wrote:
> > At first reaction, I think this goes a broader than that use case.  These
> > items aren't necessarily used with NiFi, but in support of it.  I could
> > probably go either way though.
> >
> > The Docker items, as I see them, would not be binary images, there are
> > other avenues for that.  This is largely in support of NiFi-153 and is
> > completely source driven.  The work I have done thus far is simply a
> > Dockerfile, an initialization script, and a Makefile; all source files,
> no
> > binaries (although the Makefile will retrieve a NiFi release when
> invoked).
> >
> > On Sat, Mar 21, 2015 at 2:00 PM, Joe Witt <[hidden email]> wrote:
> >
> >> Aldrin,
> >>
> >> Mark made a spark receive during this last build cycle.  It is under
> >> root/nifi/nifi-externals.  Would this cover your case or are you
> >> thinking more broadly?
> >>
> >> In the case of docker i suspect that gets blurry with the lines of
> >> binary release vs source release.  What in your view would need to
> >> live in our source for docker support?
> >>
> >> Thanks
> >> Joe
> >>
> >> On Sat, Mar 21, 2015 at 1:54 PM, Aldrin Piri <[hidden email]>
> wrote:
> >> > What is the right destination for handling, for lack of better
> phrasing
> >> > meta-source/contributions?
> >> >
> >> > This was broached briefly with the site design, but that found a home,
> >> > appropriately with the main repository at the top level.  With the
> talk
> >> of
> >> > configuration for editors as we strive towards a consistent code style
> >> and
> >> > some work I've been doing with Docker to support NiFi, where do these
> >> items
> >> > reside?
> >> >
> >> > Based on my experiences and what I have witnessed on other projects, a
> >> > contrib folder in the repository seems to be how this is classically
> >> > handled; you do not need these items, but they may be helpful.  Seems
> >> like
> >> > an appropriate fit, with some subdirectories that group these by
> intent
> >> to
> >> > avoid it becoming a dumping ground.  Any additional thoughts or
> >> suggestions
> >> > on how we can best incorporate these in a sane and organized fashion?
> >>
>