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?
Josh Elser 2013-05-17, 19:35
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

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 copy
>> it in using some other method. Those are all tangential arguments.
>> Adam
>> On Fri, May 17, 2013 at 2:49 PM, William Slacum <
>> [EMAIL PROTECTED]> wrote:
>>> I think of the native maps as an add on and they should probably be
>> treated
>>> as such. I think we should consider building a different package and
>>> installing them separately. Personally, for development and testing, I
>>> don't use them.
>>> Since we're building RPMs and debian packages, the steps to install an
>> add
>>> on is roughly 20 keystrokes.
>>> On Fri, May 17, 2013 at 2:22 PM, Josh Elser <[EMAIL PROTECTED]>
>> wrote:
>>>> I believe I already voiced my opinion on this, but let me restate it
>>> since
>>>> the conversation is happening again.
>>>> Bundling the native library built with a "common" library is easiest
>> and
>>> I
>>>> believe makes the most sense. My opinion is that source files should be
>>>> included in a source release and that a bin release doesn't include
>>> source
>>>> files. Since we're specifically making this distinction by making these
>>>> releases, it doesn't make sense to me why we would decide "oh, well in
>>> this
>>>> one case, the bin dist will actually have _some_ src files too."
>>>> Is it not intuitive that if people need to rebuild something, that they
>>>> download a src dist (and bin) to start? :shrug: