On Fri, Nov 14, 2014 at 11:16 AM, Keith Turner <ke...@deenlo.com> wrote:

> On Wed, Nov 12, 2014 at 4:52 PM, Corey Nolet <cjno...@gmail.com> wrote:
>
> > Josh,
> >
> > > My worry with a contrib module is that, historically, code which goes
> > moves to a contrib is just one step away from the grave.
> >
> > You do have a good point. My hope was that this could be the beginning of
> > our changing history so that we could begin to encourage the community to
> > contribute their own source directly and give them an outlet for doing
> so.
> > I understand that's also the intent of hosting open source repos under
> ASF
> > to begin with- so I'm partial to either outcome.
> >
> > > I think there's precedence for keeping them in core (as Christopher had
> > mentioned, next to examples/simple) which would benefit people externally
> > (more "how do I do X" examples) and internally (keep devs honest about
> how
> > our APIs are implemented).
> >
> > I would think that would just require keeping the repos up to date as
> > versions change so they wouldn't get out of date and possibly releasing
> > them w/ our other releases.
> >
> >
> > Wherever they end up living, thank you Adam for the contributions!
> >
>
> I'll 2nd that.
>
>
+1


> For the following reasons, I think it might be nice to move existing
> examples out of core into their own git repo(s).
>
>  * Examples would be based on released version of Accumulo
>  * Examples could easily be built w/o building all of Accumulo
>  * As Sean said, this would keep us honest
>  * The examples poms would serve as examples more than they do when part of
> Accumulo build
>  * Less likely to use non public APIs in examples
>
>
I don't know that a separate repo is a prerequisite for these goals. For
instance, if we had a client API jar (which we will for 2.0.0), we can have
a compile dependency on that within the examples, and only runtime-scoped
dependencies for the remaining Accumulo artifacts, in order to guarantee
we're not using non-public APIs.

I do think a lot of these goals makes sense in the context of a stable API
with version guarantees (2.0.0 and later). As a separate repo, they can
still be used in the automated build to ensure we haven't introduced
breaking changes within a version, but it would add significant extra
effort (of the chicken/egg variety) for each major release. As part of the
core repo, and with some care, it wouldn't be too hard to restrict builds
of the examples module to only major (*.0.0) releases, and it can even have
a separate versioning scheme (that does not inherit from the Accumulo
parent pom.xml). Before examples are moved to a separate repo, we're going
to have to address these issues. This discussion could be deferred to when
we are closer to considering a 2.0.0 release.


>
> >
> >
> >
> > On Wed, Nov 12, 2014 at 2:54 PM, Josh Elser <josh.el...@gmail.com>
> wrote:
> >
> > > My worry with a contrib module is that, historically, code which goes
> > > moves to a contrib is just one step away from the grave. I think
> there's
> > > precedence for keeping them in core (as Christopher had mentioned, next
> > to
> > > examples/simple) which would benefit people externally (more "how do I
> do
> > > X" examples) and internally (keep devs honest about how our APIs are
> > > implemented).
> > >
> > > Bringing the examples into the core also encourages us to grow the
> > > community which has been stagnant with respect to new committers for
> > about
> > > 9 months now.
> > >
> > >
> > > Corey Nolet wrote:
> > >
> > >> +1 for adding the examples to contrib.
> > >>
> > >> I was, myself, reading over this email wondering how a set of 11
> > separate
> > >> examples on the use of Accumulo would fit into the core codebase-
> > >> especially as more are contributed over tinme. I like the idea of
> giving
> > >> community members an outlet for contributing examples that they've
> built
> > >> so
> > >> that we can continue to foster that without having to fit them in the
> > core
> > >> codebase. It just seems more maintainable.
> > >>
> > >>
> > >> On Wed, Nov 12, 2014 at 2:19 PM, Josh Elser<josh.el...@gmail.com>
> > wrote:
> > >>
> > >>  I'll take that as you disagree with my consideration of
> "substantial".
> > >>> Thanks.
> > >>>
> > >>>
> > >>> Mike Drob wrote:
> > >>>
> > >>>  The proposed contribution is a collection of 11 examples. It's
> clearly
> > >>>> non-trivial, which is probably enough to be considered "substantial"
> > >>>>
> > >>>> On Wed, Nov 12, 2014 at 12:58 PM, Josh Elser<josh.el...@gmail.com>
> > >>>> wrote:
> > >>>>
> > >>>>
> > >>>>  Sean Busbey wrote:
> > >>>>>
> > >>>>>   On Wed, Nov 12, 2014 at 12:31 PM, Josh Elser<
> josh.el...@gmail.com>
> > >>>>>
> > >>>>>> wrote:
> > >>>>>>
> > >>>>>>    Personally, I didn't really think that this contribution was in
> > the
> > >>>>>>
> > >>>>>>  spirit
> > >>>>>>> of what the new codebase adoption guidelines were meant to cover.
> > >>>>>>>
> > >>>>>>> Some extra examples which leverage what Accumulo already does
> seems
> > >>>>>>> more
> > >>>>>>> like improvements for new Accumulo users than anything else.
> > >>>>>>>
> > >>>>>>>
> > >>>>>>>    It's content developed out side of the project list. That's
> all
> > it
> > >>>>>>>
> > >>>>>>>  takes to
> > >>>>>> require the trip through the Incubator checks as far as the ASF
> > >>>>>> guidelines
> > >>>>>> are concerned.
> > >>>>>>
> > >>>>>>
> > >>>>>>
> > >>>>>>    From http://incubator.apache.org/ip-clearance/index.html
> > >>>>>>
> > >>>>> """
> > >>>>>   From time to time, an external codebase is brought into the ASF
> > that
> > >>>>> is
> > >>>>> not a separate incubating project but still represents a
> substantial
> > >>>>> contribution that was not developed within the ASF's source control
> > >>>>> system
> > >>>>> and on our public mailing lists.
> > >>>>> """
> > >>>>>
> > >>>>> Not to look a gift-horse in the mouth (it is great work), but I
> don't
> > >>>>> see
> > >>>>> these examples as "substantial". I haven't found guidelines yet
> that
> > >>>>> better
> > >>>>> clarify the definition of "substantial".
> > >>>>>
> > >>>>>
> > >>>>>
> > >>
> >
>

Reply via email to