accumulo-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Christopher <ctubb...@apache.org>
Subject Re: Is C++ code still part of 1.5 release?
Date Fri, 17 May 2013 21:53:54 GMT
Thanks for that link, Billie. It was informative.

>From that, it seems clear that what we should focus on, is voting on,
when it comes to binary packages, is the *ability* of the source
tarball to produce the binaries that we wish it to produce, since it
is only the source package that we are voting on for the purposes of a
release. It does seem that presently, (aside from not including
*.dylib, which I think somebody mentioned), the source package is
capable of producing the binaries we wish it to.

These are a separate issue from the convenience binaries we *happen to
have produced* with that source. (which I think is still good to have
consensus on, but should not be the primary issue of holding up a
release). These are really gravy (perhaps very delicious gravy, but
still gravy).

--
Christopher L Tubbs II
http://gravatar.com/ctubbsii


On Fri, May 17, 2013 at 5:39 PM, Billie Rinaldi
<billie.rinaldi@gmail.com> wrote:
> On May 17, 2013 5:13 PM, "Adam Fuchs" <afuchs@apache.org> wrote:
>>
>> I'm with Michael on this one. We should really only be releasing one
>> package that has all of the source and built binaries. IMO the
>> interpretation of http://www.apache.org/dev/release.html that we must have
>> a source-only release is overly restrictive. "Every ASF release must
>> contain a source package, which must be sufficient for a user to build and
>> test the release provided they have access to the appropriate platform and
>> tools." can also be interpreted such that a single package with source and
>> binaries meets the release requirement.
>
> In lieu of ranting myself, I'll point you here: http://s.apache.org/nnN
>
> Billie
>
>>
>> I have seen a lot of confusion about people trying to build the accumulo
>> code when they really don't need to, and they often run into trouble when
>> their environment is not set up for java development. Having multiple
>> .tar.gz artifacts adds to this confusion. When we reordered the download
>> page so that the -dist.tar.gz came before the -src.tar.gz those types of
>> questions dropped dramatically on the mailing list. The existence of the
>> -src.tar.gz creates confusion on its own (although our README doesn't
> help).
>>
>> Adam
>>
>>
>>
>> On Fri, May 17, 2013 at 4:00 PM, Michael Berman <mberman@sqrrl.com> wrote:
>>
>> > As an Accumulo user, the thing I want most is a single package that
>> > contains the things I need to set up a running instance.  I don't want
> to
>> > build the whole thing from source, but I am happy to build the native
> map,
>> > unless every possible architecture is going to be distributed.  I really
>> > don't care at all whether the tarball name ends in "-bin" or "-package"
> or
>> > "-theStuffYouWant".  If the only reason not to include the native map
>> > sources in the binary release is because the filename ends in -bin, why
> not
>> > just call it accumulo-1.5.0.tar.gz?
>> >
>> >
>> > On Fri, May 17, 2013 at 3:51 PM, John Vines <vines@apache.org> wrote:
>> >
>> > > 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" <josh.elser@gmail.com> 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 <afuchs@apache.org>
>> > 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 <
>> > > >>> wilhelm.von.cloud@accumulo.net**> 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 <josh.elser@gmail.com
>>
>> > > >>>>
>> > > >>> 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:
>> > > >>>>>
>> > > >>>>>
>> > > >>>>>
>> > >
>> >

Mime
View raw message