Home | About | Sematext search-lucene.com search-hadoop.com
 Search Hadoop and all its subprojects:

Switch to Threaded View
Accumulo >> mail # dev >> Is C++ code still part of 1.5 release?

Copy link to this message
Re: Is C++ code still part of 1.5 release?
We should strive to deliver what we say we are delivering. Seeing a
makefile almost immediately gives a user a sense of "Oh, I have to build
something to get this work" (and I think this thread has already shown
that's the case with a user), which implies our binary release is not ready
to be run out of the box when it in fact is. There is also precedent as our
upstream projects do not ship any source beyond integration hooks. Also,
since the source does produce a platform dependent binary, and after
talking with Christopher has to be placed in a special directory at the
moment, implies to me that this is an add on that needs to do extra work
beyond just compilation. This is what packages and a package manager are
designed to handle, and they handle it very well.

The whole argument stems from not wanting to download a second,
unnecessary, thing. From a maintainability standpoint, the less we try to
do, the more consistent we'll be. The binary tarball works as is-- I don't
see the need to add things to it to avoid a second download of some source
code that you will have to manually work on any ways.
On Fri, May 17, 2013 at 4:26 PM, Billie Rinaldi <[EMAIL PROTECTED]>wrote:

> On Fri, May 17, 2013 at 12:35 PM, Josh Elser <[EMAIL PROTECTED]> wrote:
> > I'm happy we're stating our opinions here, but there are also two other
> > people who believe that the bin should not contain it. That's nice that
> you
> > want source code in a binary release, but your opinion is not the only
> one.
> > I feel like you're telling me that my opinion is sub-par to your opinion
> > because it is.
> >
> > If this is such a sticking point, I move that we completely kill the
> > notion of source and binary releases and make one tarball that contains
> > both.
> There must be a source-only tarball.  (I am aware that Hadoop and other
> projects do not always abide by ASF policy in this matter.)  The source is
> considered the release.  We may, for the convenience of our users, create
> additional packages built from the source release.  It doesn't matter if
> these are binary-only or source+binary, as long as they don't contain
> additional source or binaries built from source not included in the
> canonical source tarball / SVN tag.
> http://www.apache.org/dev/release.html
> We already have some source in the binary release: the java code for the
> examples, which is there as documentation.  So we probably shouldn't sweat
> too much over the label "binary".  I personally like pre-built packages
> that contain all the source code, but I don't mind trying out a streamlined
> package for this release.
> It does seem like we should either provide a bunch of pre-built native
> libs, or make it easy for people to generate their own.
> Billie
> >
> > On 5/17/13 3:17 PM, John Vines wrote:
> >
> >> I agree with Adam. It seems like it's a debate of consistency vs.
> >> pragmatism. The cost of including these libraries are all of maybe 1kb
> in
> >> the package. The cost of excluding them is potential frustration from
> end
> >> users and a lot of repetitive stress against the Apache Mirrors (lets
> try
> >> and be considerate). I think it's a no brainer, but I have yet to here a
> >> reason that is not 'no source code in a binary release!'
> >>
> >>
> >> On Fri, May 17, 2013 at 12:11 PM, Adam Fuchs <[EMAIL PROTECTED]> wrote:
> >>
> >>  Just to solidify the decision that Chris is already leaning towards,
> let
> >>> me
> >>> try to clarify my position:
> >>> 1. The only reason not to add the native library source code in the
> >>> -bin.tar.gz distribution is that src != bin. There is no measurable
> >>> negative effect of putting the cpp files and Makefile into the
> >>> -bin.tar.gz.
> >>> 2. At least one person wants the native library source code in the
> >>> -bin.tar.gz to make their life easier.
> >>>
> >>> This is a very simple decision. It really doesn't matter how easy it is
> >>> to
> >>> include prebuilt native code in some other way or build the code and