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?
Billie Rinaldi 2013-05-17, 20:26
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 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