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?
John Vines 2013-05-17, 19:51
If we're going to be making binary releases that have no other mechanism
for creating the native libraries, then we should probably cut a few
different binary releases for x86, amd64, and darwin at the very least.

Sent from my phone, please pardon the typos and brevity.
On May 17, 2013 12:36 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.
>
> 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:
>>>>>
>>>>>
>>>>>