Re: Is C++ code still part of 1.5 release?
I went through all the rpms and debs and tarballs to check to see if they were including the right things (ACCUMULO-1404). Personally, I don't think they should be in a binary-release... source code that needs to be compiled sounds like something you'd get out of the source tarball, so I assumed its inclusion was an oversight that I was correcting. (I did make sure the *.so files were included.) If there's a reason to keep source code in a binary package, then, I can add it back in, but really, if you can't use it out of the box, I'm not sure it should be in the binary tarball. This is related to another issue I was looking at also, so i'll mention it here: What do we include for proxy thrift bindings? I see that currently we're dropping in the gen-rb, gen-java, and gen-py folders from the proxy thrift compilation. However, I'm not so sure we should be doing this... because: 1) we don't need to include java bindings for the proxy; compiled versions are already in the proxy jar, 2) not all packagers will even have installed thrift with the ability to produce ruby and python bindings, 3) these may or may not be helpful to any particular end user (though it's probably safe to assume ruby and python will be the most common), 4) we're not including the proxy.thrift file, which is perhaps the most important file for the proxy, and including it should be sufficient. -- Christopher L Tubbs II http://gravatar.com/ctubbsii On Sun, May 12, 2013 at 11:22 PM, David Medinets wrote: > I ran this command: > > git clone --branch 1.5 https://github.com/apache/accumulo.git > > then compiled to get a binary-release.tar.gz file. That gz file does not > seem to contain the C++ files to build the native libraries. Should they be > there? I don't recall hearing about removing them.
Re: Is C++ code still part of 1.5 release?
What other things should be included in the binary packaging that aren't, and what other things are included that shouldn't be? -- Christopher L Tubbs II http://gravatar.com/ctubbsii On Sun, May 12, 2013 at 11:45 PM, Christopher wrote: > I went through all the rpms and debs and tarballs to check to see if > they were including the right things (ACCUMULO-1404). > > Personally, I don't think they should be in a binary-release... source > code that needs to be compiled sounds like something you'd get out of > the source tarball, so I assumed its inclusion was an oversight that I > was correcting. (I did make sure the *.so files were included.) If > there's a reason to keep source code in a binary package, then, I can > add it back in, but really, if you can't use it out of the box, I'm > not sure it should be in the binary tarball. > > This is related to another issue I was looking at also, so i'll mention it > here: > What do we include for proxy thrift bindings? I see that currently > we're dropping in the gen-rb, gen-java, and gen-py folders from the > proxy thrift compilation. However, I'm not so sure we should be doing > this... because: > > 1) we don't need to include java bindings for the proxy; compiled > versions are already in the proxy jar, > 2) not all packagers will even have installed thrift with the ability > to produce ruby and python bindings, > 3) these may or may not be helpful to any particular end user (though > it's probably safe to assume ruby and python will be the most common), > 4) we're not including the proxy.thrift file, which is perhaps the > most important file for the proxy, and including it should be > sufficient. > > > > -- > Christopher L Tubbs II > http://gravatar.com/ctubbsii > > > On Sun, May 12, 2013 at 11:22 PM, David Medinets > wrote: >> I ran this command: >> >> git clone --branch 1.5 https://github.com/apache/accumulo.git >> >> then compiled to get a binary-release.tar.gz file. That gz file does not >> seem to contain the C++ files to build the native libraries. Should they be >> there? I don't recall hearing about removing them.
Re: Is C++ code still part of 1.5 release?
The results of the c++ compilation are .so files which are already in the binary.release.tar.gz file. And after I untag that .gz into my installation directory, the .so files will be in the correct location for Accumulo to find them? On Sun, May 12, 2013 at 11:46 PM, Christopher wrote: > What other things should be included in the binary packaging that > aren't, and what other things are included that shouldn't be? > > -- > Christopher L Tubbs II > http://gravatar.com/ctubbsii > > > On Sun, May 12, 2013 at 11:45 PM, Christopher wrote: > > I went through all the rpms and debs and tarballs to check to see if > > they were including the right things (ACCUMULO-1404). > > > > Personally, I don't think they should be in a binary-release... source > > code that needs to be compiled sounds like something you'd get out of > > the source tarball, so I assumed its inclusion was an oversight that I > > was correcting. (I did make sure the *.so files were included.) If > > there's a reason to keep source code in a binary package, then, I can > > add it back in, but really, if you can't use it out of the box, I'm > > not sure it should be in the binary tarball. > > > > This is related to another issue I was looking at also, so i'll mention > it here: > > What do we include for proxy thrift bindings? I see that currently > > we're dropping in the gen-rb, gen-java, and gen-py folders from the > > proxy thrift compilation. However, I'm not so sure we should be doing > > this... because: > > > > 1) we don't need to include java bindings for the proxy; compiled > > versions are already in the proxy jar, > > 2) not all packagers will even have installed thrift with the ability > > to produce ruby and python bindings, > > 3) these may or may not be helpful to any particular end user (though > > it's probably safe to assume ruby and python will be the most common), > > 4) we're not including the proxy.thrift file, which is perhaps the > > most important file for the proxy, and including it should be > > sufficient. > > > > > > > > -- > > Christopher L Tubbs II > > http://gravatar.com/ctubbsii > > > > > > On Sun, May 12, 2013 at 11:22 PM, David Medinets > > wrote: > >> I ran this command: > >> > >> git clone --branch 1.5 https://github.com/apache/accumulo.git > >> > >> then compiled to get a binary-release.tar.gz file. That gz file does not > >> seem to contain the C++ files to build the native libraries. Should > they be > >> there? I don't recall hearing about removing them. >
Re: Is C++ code still part of 1.5 release?
Yes, they should be. -- Christopher L Tubbs II http://gravatar.com/ctubbsii On Mon, May 13, 2013 at 8:26 AM, David Medinets wrote: > The results of the c++ compilation are .so files which are already in the > binary.release.tar.gz file. And after I untag that .gz into my installation > directory, the .so files will be in the correct location for Accumulo to > find them? > > > On Sun, May 12, 2013 at 11:46 PM, Christopher wrote: > >> What other things should be included in the binary packaging that >> aren't, and what other things are included that shouldn't be? >> >> -- >> Christopher L Tubbs II >> http://gravatar.com/ctubbsii >> >> >> On Sun, May 12, 2013 at 11:45 PM, Christopher wrote: >> > I went through all the rpms and debs and tarballs to check to see if >> > they were including the right things (ACCUMULO-1404). >> > >> > Personally, I don't think they should be in a binary-release... source >> > code that needs to be compiled sounds like something you'd get out of >> > the source tarball, so I assumed its inclusion was an oversight that I >> > was correcting. (I did make sure the *.so files were included.) If >> > there's a reason to keep source code in a binary package, then, I can >> > add it back in, but really, if you can't use it out of the box, I'm >> > not sure it should be in the binary tarball. >> > >> > This is related to another issue I was looking at also, so i'll mention >> it here: >> > What do we include for proxy thrift bindings? I see that currently >> > we're dropping in the gen-rb, gen-java, and gen-py folders from the >> > proxy thrift compilation. However, I'm not so sure we should be doing >> > this... because: >> > >> > 1) we don't need to include java bindings for the proxy; compiled >> > versions are already in the proxy jar, >> > 2) not all packagers will even have installed thrift with the ability >> > to produce ruby and python bindings, >> > 3) these may or may not be helpful to any particular end user (though >> > it's probably safe to assume ruby and python will be the most common), >> > 4) we're not including the proxy.thrift file, which is perhaps the >> > most important file for the proxy, and including it should be >> > sufficient. >> > >> > >> > >> > -- >> > Christopher L Tubbs II >> > http://gravatar.com/ctubbsii >> > >> > >> > On Sun, May 12, 2013 at 11:22 PM, David Medinets >> > wrote: >> >> I ran this command: >> >> >> >> git clone --branch 1.5 https://github.com/apache/accumulo.git >> >> >> >> then compiled to get a binary-release.tar.gz file. That gz file does not >> >> seem to contain the C++ files to build the native libraries. Should >> they be >> >> there? I don't recall hearing about removing them. >>
Re: Is C++ code still part of 1.5 release?
On Sun, May 12, 2013 at 8:45 PM, Christopher wrote: > I went through all the rpms and debs and tarballs to check to see if > they were including the right things (ACCUMULO-1404). > > Personally, I don't think they should be in a binary-release... source > code that needs to be compiled sounds like something you'd get out of > the source tarball, so I assumed its inclusion was an oversight that I > was correcting. (I did make sure the *.so files were included.) If > there's a reason to keep source code in a binary package, then, I can > add it back in, but really, if you can't use it out of the box, I'm > not sure it should be in the binary tarball. > This would be a change from what we were doing with "dist" releases, but I am not necessarily against it. I find it nice to have the source there, as I often look things up in it. To reproduce the previous structure, would I be able to just unpack the source release over the binary release? Billie > This is related to another issue I was looking at also, so i'll mention it > here: > What do we include for proxy thrift bindings? I see that currently > we're dropping in the gen-rb, gen-java, and gen-py folders from the > proxy thrift compilation. However, I'm not so sure we should be doing > this... because: > > 1) we don't need to include java bindings for the proxy; compiled > versions are already in the proxy jar, > 2) not all packagers will even have installed thrift with the ability > to produce ruby and python bindings, > 3) these may or may not be helpful to any particular end user (though > it's probably safe to assume ruby and python will be the most common), > 4) we're not including the proxy.thrift file, which is perhaps the > most important file for the proxy, and including it should be > sufficient. > > > > -- > Christopher L Tubbs II > http://gravatar.com/ctubbsii > > > On Sun, May 12, 2013 at 11:22 PM, David Medinets > wrote: > > I ran this command: > > > > git clone --branch 1.5 https://github.com/apache/accumulo.git > > > > then compiled to get a binary-release.tar.gz file. That gz file does not > > seem to contain the C++ files to build the native libraries. Should they > be > > there? I don't recall hearing about removing them. >
Re: Is C++ code still part of 1.5 release?
On 5/12/13 11:45 PM, Christopher wrote: 1) we don't need to include java bindings for the proxy; compiled versions are already in the proxy jar, 2) not all packagers will even have installed thrift with the ability to produce ruby and python bindings, 3) these may or may not be helpful to any particular end user (though it's probably safe to assume ruby and python will be the most common), 4) we're not including the proxy.thrift file, which is perhaps the most important file for the proxy, and including it should be sufficient. 1)That works. I should've caught that when I was in the proxy last and I didn't.Thanks for that. 2) Do you mean packagers as in people who might make an official release? I would think these are the only people that "really" matter, and thus I would expect them to be able to build a full distributionthat include these bindings. It might be nice to be able to create a packaging for each language (gem, egg, etc); but until we have some sort of packaging, I'd really like to see theruby and pythonsources included even in the binary dist. 3)True, but I'd rather set the bar as low as possible for people who just want to play around in a scripting language with Accumulo. 4) Definitely want to make sure it's included. Does anyone have an opinion on other languages that thrift supports that we should also create bindings for? I concur with your opinion on Ruby and Python, but I wonder if there's something else that people would also like.
Re: Is C++ code still part of 1.5 release?
2) Yes. 3) True, I think gen-py, and gen-rb, should be included as a minimum. I'm not sure about gen-cpp... but I can include it, as I tried to install thrift with maximum options enabled. -- Christopher L Tubbs II http://gravatar.com/ctubbsii On Mon, May 13, 2013 at 10:40 AM, Josh Elser wrote: > On 5/12/13 11:45 PM, Christopher wrote: >> >> 1) we don't need to include java bindings for the proxy; compiled >> versions are already in the proxy jar, >> 2) not all packagers will even have installed thrift with the ability >> to produce ruby and python bindings, >> 3) these may or may not be helpful to any particular end user (though >> it's probably safe to assume ruby and python will be the most common), >> 4) we're not including the proxy.thrift file, which is perhaps the >> most important file for the proxy, and including it should be >> sufficient. >> >> > 1)That works. I should've caught that when I was in the proxy last and I > didn't.Thanks for that. > 2) Do you mean packagers as in people who might make an official release? I > would think these are the only people that "really" matter, and thus I would > expect them to be able to build a full distributionthat include these > bindings. It might be nice to be able to create a packaging for each > language (gem, egg, etc); but until we have some sort of packaging, I'd > really like to see theruby and pythonsources included even in the binary > dist. > 3)True, but I'd rather set the bar as low as possible for people who just > want to play around in a scripting language with Accumulo. > 4) Definitely want to make sure it's included. > > Does anyone have an opinion on other languages that thrift supports that we > should also create bindings for? I concur with your opinion on Ruby and > Python, but I wonder if there's something else that people would also like.
Re: Is C++ code still part of 1.5 release?
Yeah, you could essentially unpack the source over the binary... for now, anyway... but some things would be slightly different. Like the addition of the proxy/thrift directory for the generated thrift bindings pulled out of proxy/target/. But... I really don't think it should be a goal to make the source directory structure and the binary directory structure overlap like this. The binary tarball should really just a "ready to use" thing, and the source should be a "ready to develop or re-package" thing. -- Christopher L Tubbs II http://gravatar.com/ctubbsii On Mon, May 13, 2013 at 10:21 AM, Billie Rinaldi wrote: > On Sun, May 12, 2013 at 8:45 PM, Christopher wrote: > >> I went through all the rpms and debs and tarballs to check to see if >> they were including the right things (ACCUMULO-1404). >> >> Personally, I don't think they should be in a binary-release... source >> code that needs to be compiled sounds like something you'd get out of >> the source tarball, so I assumed its inclusion was an oversight that I >> was correcting. (I did make sure the *.so files were included.) If >> there's a reason to keep source code in a binary package, then, I can >> add it back in, but really, if you can't use it out of the box, I'm >> not sure it should be in the binary tarball. >> > > This would be a change from what we were doing with "dist" releases, but I > am not necessarily against it. I find it nice to have the source there, as > I often look things up in it. To reproduce the previous structure, would I > be able to just unpack the source release over the binary release? > > Billie > > >> This is related to another issue I was looking at also, so i'll mention it >> here: >> What do we include for proxy thrift bindings? I see that currently >> we're dropping in the gen-rb, gen-java, and gen-py folders from the >> proxy thrift compilation. However, I'm not so sure we should be doing >> this... because: >> >> 1) we don't need to include java bindings for the proxy; compiled >> versions are already in the proxy jar, >> 2) not all packagers will even have installed thrift with the ability >> to produce ruby and python bindings, >> 3) these may or may not be helpful to any particular end user (though >> it's probably safe to assume ruby and python will be the most common), >> 4) we're not including the proxy.thrift file, which is perhaps the >> most important file for the proxy, and including it should be >> sufficient. >> >> >> >> -- >> Christopher L Tubbs II >> http://gravatar.com/ctubbsii >> >> >> On Sun, May 12, 2013 at 11:22 PM, David Medinets >> wrote: >> > I ran this command: >> > >> > git clone --branch 1.5 https://github.com/apache/accumulo.git >> > >> > then compiled to get a binary-release.tar.gz file. That gz file does not >> > seem to contain the C++ files to build the native libraries. Should they >> be >> > there? I don't recall hearing about removing them. >>
Re: Is C++ code still part of 1.5 release?
That sounds like a tremendous headache for the users where the pre-built native libraries aren't sufficient. On Mon, May 13, 2013 at 11:13 AM, Christopher wrote: > Yeah, you could essentially unpack the source over the binary... for > now, anyway... but some things would be slightly different. Like the > addition of the proxy/thrift directory for the generated thrift > bindings pulled out of proxy/target/. But... I really don't think it > should be a goal to make the source directory structure and the binary > directory structure overlap like this. The binary tarball should > really just a "ready to use" thing, and the source should be a "ready > to develop or re-package" thing. > > -- > Christopher L Tubbs II > http://gravatar.com/ctubbsii > > > On Mon, May 13, 2013 at 10:21 AM, Billie Rinaldi > wrote: > > On Sun, May 12, 2013 at 8:45 PM, Christopher > wrote: > > > >> I went through all the rpms and debs and tarballs to check to see if > >> they were including the right things (ACCUMULO-1404). > >> > >> Personally, I don't think they should be in a binary-release... source > >> code that needs to be compiled sounds like something you'd get out of > >> the source tarball, so I assumed its inclusion was an oversight that I > >> was correcting. (I did make sure the *.so files were included.) If > >> there's a reason to keep source code in a binary package, then, I can > >> add it back in, but really, if you can't use it out of the box, I'm > >> not sure it should be in the binary tarball. > >> > > > > This would be a change from what we were doing with "dist" releases, but > I > > am not necessarily against it. I find it nice to have the source there, > as > > I often look things up in it. To reproduce the previous structure, > would I > > be able to just unpack the source release over the binary release? > > > > Billie > > > > > >> This is related to another issue I was looking at also, so i'll mention > it > >> here: > >> What do we include for proxy thrift bindings? I see that currently > >> we're dropping in the gen-rb, gen-java, and gen-py folders from the > >> proxy thrift compilation. However, I'm not so sure we should be doing > >> this... because: > >> > >> 1) we don't need to include java bindings for the proxy; compiled > >> versions are already in the proxy jar, > >> 2) not all packagers will even have installed thrift with the ability > >> to produce ruby and python bindings, > >> 3) these may or may not be helpful to any particular end user (though > >> it's probably safe to assume ruby and python will be the most common), > >> 4) we're not including the proxy.thrift file, which is perhaps the > >> most important file for the proxy, and including it should be > >> sufficient. > >> > >> > >> > >> -- > >> Christopher L Tubbs II > >> http://gravatar.com/ctubbsii > >> > >> > >> On Sun, May 12, 2013 at 11:22 PM, David Medinets > >> wrote: > >> > I ran this command: > >> > > >> > git clone --branch 1.5 https://github.com/apache/accumulo.git > >> > > >> > then compiled to get a binary-release.tar.gz file. That gz file does > not > >> > seem to contain the C++ files to build the native libraries. Should > they > >> be > >> > there? I don't recall hearing about removing them. > >> >
Re: Is C++ code still part of 1.5 release?
I question whether the following four steps should be considered a "tremendous headache", simply because of the fact that one needs to download a different file than the one already downloaded... 1. Download source tarball 2. Unpack source tarball 3. Navigate to server/src/main/c++ 4. Run "make" ... but I can easily add it back in if that's the consensus. -- Christopher L Tubbs II http://gravatar.com/ctubbsii On Mon, May 13, 2013 at 11:34 AM, John Vines wrote: > That sounds like a tremendous headache for the users where the pre-built > native libraries aren't sufficient. > > > On Mon, May 13, 2013 at 11:13 AM, Christopher wrote: > >> Yeah, you could essentially unpack the source over the binary... for >> now, anyway... but some things would be slightly different. Like the >> addition of the proxy/thrift directory for the generated thrift >> bindings pulled out of proxy/target/. But... I really don't think it >> should be a goal to make the source directory structure and the binary >> directory structure overlap like this. The binary tarball should >> really just a "ready to use" thing, and the source should be a "ready >> to develop or re-package" thing. >> >> -- >> Christopher L Tubbs II >> http://gravatar.com/ctubbsii >> >> >> On Mon, May 13, 2013 at 10:21 AM, Billie Rinaldi >> wrote: >> > On Sun, May 12, 2013 at 8:45 PM, Christopher >> wrote: >> > >> >> I went through all the rpms and debs and tarballs to check to see if >> >> they were including the right things (ACCUMULO-1404). >> >> >> >> Personally, I don't think they should be in a binary-release... source >> >> code that needs to be compiled sounds like something you'd get out of >> >> the source tarball, so I assumed its inclusion was an oversight that I >> >> was correcting. (I did make sure the *.so files were included.) If >> >> there's a reason to keep source code in a binary package, then, I can >> >> add it back in, but really, if you can't use it out of the box, I'm >> >> not sure it should be in the binary tarball. >> >> >> > >> > This would be a change from what we were doing with "dist" releases, but >> I >> > am not necessarily against it. I find it nice to have the source there, >> as >> > I often look things up in it. To reproduce the previous structure, >> would I >> > be able to just unpack the source release over the binary release? >> > >> > Billie >> > >> > >> >> This is related to another issue I was looking at also, so i'll mention >> it >> >> here: >> >> What do we include for proxy thrift bindings? I see that currently >> >> we're dropping in the gen-rb, gen-java, and gen-py folders from the >> >> proxy thrift compilation. However, I'm not so sure we should be doing >> >> this... because: >> >> >> >> 1) we don't need to include java bindings for the proxy; compiled >> >> versions are already in the proxy jar, >> >> 2) not all packagers will even have installed thrift with the ability >> >> to produce ruby and python bindings, >> >> 3) these may or may not be helpful to any particular end user (though >> >> it's probably safe to assume ruby and python will be the most common), >> >> 4) we're not including the proxy.thrift file, which is perhaps the >> >> most important file for the proxy, and including it should be >> >> sufficient. >> >> >> >> >> >> >> >> -- >> >> Christopher L Tubbs II >> >> http://gravatar.com/ctubbsii >> >> >> >> >> >> On Sun, May 12, 2013 at 11:22 PM, David Medinets >> >> wrote: >> >> > I ran this command: >> >> > >> >> > git clone --branch 1.5 https://github.com/apache/accumulo.git >> >> > >> >> > then compiled to get a binary-release.tar.gz file. That gz file does >> not >> >> > seem to contain the C++ files to build the native libraries. Should >> they >> >> be >> >> > there? I don't recall hearing about removing them. >> >> >>
Re: Is C++ code still part of 1.5 release?
How come perl is getting no love? On Mon, May 13, 2013 at 10:40 AM, Josh Elser wrote: > On 5/12/13 11:45 PM, Christopher wrote: > >> 1) we don't need to include java bindings for the proxy; compiled >> versions are already in the proxy jar, >> 2) not all packagers will even have installed thrift with the ability >> to produce ruby and python bindings, >> 3) these may or may not be helpful to any particular end user (though >> it's probably safe to assume ruby and python will be the most common), >> 4) we're not including the proxy.thrift file, which is perhaps the >> most important file for the proxy, and including it should be >> sufficient. >> >> >> 1)That works. I should've caught that when I was in the proxy last and I > didn't.Thanks for that. > 2) Do you mean packagers as in people who might make an official release? > I would think these are the only people that "really" matter, and thus I > would expect them to be able to build a full distributionthat include these > bindings. It might be nice to be able to create a packaging for each > language (gem, egg, etc); but until we have some sort of packaging, I'd > really like to see theruby and pythonsources included even in the binary > dist. > 3)True, but I'd rather set the bar as low as possible for people who just > want to play around in a scripting language with Accumulo. > 4) Definitely want to make sure it's included. > > Does anyone have an opinion on other languages that thrift supports that > we should also create bindings for? I concur with your opinion on Ruby and > Python, but I wonder if there's something else that people would also like. >
Re: Is C++ code still part of 1.5 release?
I agree with you, Christopher. I don't think it's unreasonable to expect a user to download something else if the packaged .so doesn't work on a user's system. Write that down, etc, etc. But, that does beg the question: what version of glibc are we going to build against? That could influence my opinion on the subject.. On 05/13/2013 05:18 PM, Christopher wrote: I question whether the following four steps should be considered a "tremendous headache", simply because of the fact that one needs to download a different file than the one already downloaded... 1. Download source tarball 2. Unpack source tarball 3. Navigate to server/src/main/c++ 4. Run "make" ... but I can easily add it back in if that's the consensus. -- Christopher L Tubbs II http://gravatar.com/ctubbsii On Mon, May 13, 2013 at 11:34 AM, John Vines wrote: That sounds like a tremendous headache for the users where the pre-built native libraries aren't sufficient. On Mon, May 13, 2013 at 11:13 AM, Christopher wrote: Yeah, you could essentially unpack the source over the binary... for now, anyway... but some things would be slightly different. Like the addition of the proxy/thrift directory for the generated thrift bindings pulled out of proxy/target/. But... I really don't think it should be a goal to make the source directory structure and the binary directory structure overlap like this. The binary tarball should really just a "ready to use" thing, and the source should be a "ready to develop or re-package" thing. -- Christopher L Tubbs II http://gravatar.com/ctubbsii On Mon, May 13, 2013 at 10:21 AM, Billie Rinaldi wrote: On Sun, May 12, 2013 at 8:45 PM, Christopher wrote: I went through all the rpms and debs and tarballs to check to see if they were including the right things (ACCUMULO-1404). Personally, I don't think they should be in a binary-release... source code that needs to be compiled sounds like something you'd get out of the source tarball, so I assumed its inclusion was an oversight that I was correcting. (I did make sure the *.so files were included.) If there's a reason to keep source code in a binary package, then, I can add it back in, but really, if you can't use it out of the box, I'm not sure it should be in the binary tarball. This would be a change from what we were doing with "dist" releases, but I am not necessarily against it. I find it nice to have the source there, as I often look things up in it. To reproduce the previous structure, would I be able to just unpack the source release over the binary release? Billie This is related to another issue I was looking at also, so i'll mention it here: What do we include for proxy thrift bindings? I see that currently we're dropping in the gen-rb, gen-java, and gen-py folders from the proxy thrift compilation. However, I'm not so sure we should be doing this... because: 1) we don't need to include java bindings for the proxy; compiled versions are already in the proxy jar, 2) not all packagers will even have installed thrift with the ability to produce ruby and python bindings, 3) these may or may not be helpful to any particular end user (though it's probably safe to assume ruby and python will be the most common), 4) we're not including the proxy.thrift file, which is perhaps the most important file for the proxy, and including it should be sufficient. -- Christopher L Tubbs II http://gravatar.com/ctubbsii On Sun, May 12, 2013 at 11:22 PM, David Medinets wrote: I ran this command: git clone --branch 1.5 https://github.com/apache/accumulo.git then compiled to get a binary-release.tar.gz file. That gz file does not seem to contain the C++ files to build the native libraries. Should they be there? I don't recall hearing about removing them.
Re: Is C++ code still part of 1.5 release?
Well, I'm building against the latest in CentOS 6, so that's glibc 2.12. It's also relevant to ask the platform for another reason: RPMs. The RPM I'm building is CentOS 6, and I know that's got some compatibility issues with RHEL/CentOS 5. -- Christopher L Tubbs II http://gravatar.com/ctubbsii On Mon, May 13, 2013 at 7:37 PM, Josh Elser wrote: > I agree with you, Christopher. I don't think it's unreasonable to expect a > user to download something else if the packaged .so doesn't work on a user's > system. Write that down, etc, etc. > > But, that does beg the question: what version of glibc are we going to build > against? That could influence my opinion on the subject.. > > > On 05/13/2013 05:18 PM, Christopher wrote: >> >> I question whether the following four steps should be considered a >> "tremendous headache", simply because of the fact that one needs to >> download a different file than the one already downloaded... >> >> 1. Download source tarball >> 2. Unpack source tarball >> 3. Navigate to server/src/main/c++ >> 4. Run "make" >> >> ... but I can easily add it back in if that's the consensus. >> >> >> -- >> Christopher L Tubbs II >> http://gravatar.com/ctubbsii >> >> >> On Mon, May 13, 2013 at 11:34 AM, John Vines wrote: >>> >>> That sounds like a tremendous headache for the users where the pre-built >>> native libraries aren't sufficient. >>> >>> >>> On Mon, May 13, 2013 at 11:13 AM, Christopher >>> wrote: >>> Yeah, you could essentially unpack the source over the binary... for now, anyway... but some things would be slightly different. Like the addition of the proxy/thrift directory for the generated thrift bindings pulled out of proxy/target/. But... I really don't think it should be a goal to make the source directory structure and the binary directory structure overlap like this. The binary tarball should really just a "ready to use" thing, and the source should be a "ready to develop or re-package" thing. -- Christopher L Tubbs II http://gravatar.com/ctubbsii On Mon, May 13, 2013 at 10:21 AM, Billie Rinaldi wrote: > > On Sun, May 12, 2013 at 8:45 PM, Christopher wrote: > > >> I went through all the rpms and debs and tarballs to check to see if >> they were including the right things (ACCUMULO-1404). >> >> Personally, I don't think they should be in a binary-release... source >> code that needs to be compiled sounds like something you'd get out of >> the source tarball, so I assumed its inclusion was an oversight that I >> was correcting. (I did make sure the *.so files were included.) If >> there's a reason to keep source code in a binary package, then, I can >> add it back in, but really, if you can't use it out of the box, I'm >> not sure it should be in the binary tarball. >> > > This would be a change from what we were doing with "dist" releases, > but I > > am not necessarily against it. I find it nice to have the source > there, as > > I often look things up in it. To reproduce the previous structure, would I > > be able to just unpack the source release over the binary release? > > Billie > > >> This is related to another issue I was looking at also, so i'll >> mention it >> >> here: >> What do we include for proxy thrift bindings? I see that currently >> we're dropping in the gen-rb, gen-java, and gen-py folders from the >> proxy thrift compilation. However, I'm not so sure we should be doing >> this... because: >> >> 1) we don't need to include java bindings for the proxy; compiled >> versions are already in the proxy jar, >> 2) not all packagers will even have installed thrift with the ability >> to produce ruby and python bindings, >> 3) these may or may not be helpful to any particular end user (though >> it's probably safe to assume ruby and python will be the most common), >> 4) we're not including the proxy.thrift file, which is perhaps the >> most important file for the proxy, and including it should be >> sufficient. >> >> >> >> -- >> Christopher L Tubbs II >> http://gravatar.com/ctubbsii >> >> >> On Sun, May 12, 2013 at 11:22 PM, David Medinets >> wrote: >>> >>> I ran this command: >>> >>> git clone --branch 1.5 https://github.com/apache/accumulo.git >>> >>> then compiled to get a binary-release.tar.gz file. That gz file does not >>> >>> seem to contain the C++ files to build the native libraries. Should they >> >> be >>> >>> there? I don't recall hearing about removing them. >> >> >
Re: Is C++ code still part of 1.5 release?
I could include perl... I do have thrift compiled on my build VM with perl enabled. -- Christopher L Tubbs II http://gravatar.com/ctubbsii On Mon, May 13, 2013 at 5:29 PM, David Medinets wrote: > How come perl is getting no love? > > > On Mon, May 13, 2013 at 10:40 AM, Josh Elser wrote: > >> On 5/12/13 11:45 PM, Christopher wrote: >> >>> 1) we don't need to include java bindings for the proxy; compiled >>> versions are already in the proxy jar, >>> 2) not all packagers will even have installed thrift with the ability >>> to produce ruby and python bindings, >>> 3) these may or may not be helpful to any particular end user (though >>> it's probably safe to assume ruby and python will be the most common), >>> 4) we're not including the proxy.thrift file, which is perhaps the >>> most important file for the proxy, and including it should be >>> sufficient. >>> >>> >>> 1)That works. I should've caught that when I was in the proxy last and I >> didn't.Thanks for that. >> 2) Do you mean packagers as in people who might make an official release? >> I would think these are the only people that "really" matter, and thus I >> would expect them to be able to build a full distributionthat include these >> bindings. It might be nice to be able to create a packaging for each >> language (gem, egg, etc); but until we have some sort of packaging, I'd >> really like to see theruby and pythonsources included even in the binary >> dist. >> 3)True, but I'd rather set the bar as low as possible for people who just >> want to play around in a scripting language with Accumulo. >> 4) Definitely want to make sure it's included. >> >> Does anyone have an opinion on other languages that thrift supports that >> we should also create bindings for? I concur with your opinion on Ruby and >> Python, but I wonder if there's something else that people would also like. >>
Re: Is C++ code still part of 1.5 release?
Rumor has it that one of the core developers is irrationally hostile to perl. And octal. And xml. He's just old and cranky. -Eric On Mon, May 13, 2013 at 5:29 PM, David Medinets wrote: > How come perl is getting no love? > > > On Mon, May 13, 2013 at 10:40 AM, Josh Elser wrote: > > > On 5/12/13 11:45 PM, Christopher wrote: > > > >> 1) we don't need to include java bindings for the proxy; compiled > >> versions are already in the proxy jar, > >> 2) not all packagers will even have installed thrift with the ability > >> to produce ruby and python bindings, > >> 3) these may or may not be helpful to any particular end user (though > >> it's probably safe to assume ruby and python will be the most common), > >> 4) we're not including the proxy.thrift file, which is perhaps the > >> most important file for the proxy, and including it should be > >> sufficient. > >> > >> > >> 1)That works. I should've caught that when I was in the proxy last and > I > > didn't.Thanks for that. > > 2) Do you mean packagers as in people who might make an official release? > > I would think these are the only people that "really" matter, and thus I > > would expect them to be able to build a full distributionthat include > these > > bindings. It might be nice to be able to create a packaging for each > > language (gem, egg, etc); but until we have some sort of packaging, I'd > > really like to see theruby and pythonsources included even in the binary > > dist. > > 3)True, but I'd rather set the bar as low as possible for people who just > > want to play around in a scripting language with Accumulo. > > 4) Definitely want to make sure it's included. > > > > Does anyone have an opinion on other languages that thrift supports that > > we should also create bindings for? I concur with your opinion on Ruby > and > > Python, but I wonder if there's something else that people would also > like. > > >
Re: Is C++ code still part of 1.5 release?
Folks, Sorry to be late to the party, but did we come to a consensus on this? Seems like we still have opinions both ways as to whether the cpp code should be packaged with the binary distribution. I would argue that cpp code is a special case, since the build is so platform dependent. It's generally hard to distribute the right .so files to cover all platforms, and we have run into many cases in practice where the native maps don't work out of the box. While downloading the source and untarring it over the same directory is not too much extra work, it seems like the only argument not to package the native source code with the binary distribution is a dogmatic one. Are there any practical reasons why it would be bad to add the cpp file to the bin distribution? Adam On Mon, May 13, 2013 at 10:48 PM, Eric Newton wrote: > Rumor has it that one of the core developers is irrationally hostile to > perl. > > And octal. > > And xml. > > He's just old and cranky. > > -Eric > > > On Mon, May 13, 2013 at 5:29 PM, David Medinets >wrote: > > > How come perl is getting no love? > > > > > > On Mon, May 13, 2013 at 10:40 AM, Josh Elser > wrote: > > > > > On 5/12/13 11:45 PM, Christopher wrote: > > > > > >> 1) we don't need to include java bindings for the proxy; compiled > > >> versions are already in the proxy jar, > > >> 2) not all packagers will even have installed thrift with the ability > > >> to produce ruby and python bindings, > > >> 3) these may or may not be helpful to any particular end user (though > > >> it's probably safe to assume ruby and python will be the most common), > > >> 4) we're not including the proxy.thrift file, which is perhaps the > > >> most important file for the proxy, and including it should be > > >> sufficient. > > >> > > >> > > >> 1)That works. I should've caught that when I was in the proxy last > and > > I > > > didn't.Thanks for that. > > > 2) Do you mean packagers as in people who might make an official > release? > > > I would think these are the only people that "really" matter, and thus > I > > > would expect them to be able to build a full distributionthat include > > these > > > bindings. It might be nice to be able to create a packaging for each > > > language (gem, egg, etc); but until we have some sort of packaging, I'd > > > really like to see theruby and pythonsources included even in the > binary > > > dist. > > > 3)True, but I'd rather set the bar as low as possible for people who > just > > > want to play around in a scripting language with Accumulo. > > > 4) Definitely want to make sure it's included. > > > > > > Does anyone have an opinion on other languages that thrift supports > that > > > we should also create bindings for? I concur with your opinion on Ruby > > and > > > Python, but I wonder if there's something else that people would also > > like. > > > > > >
Re: Is C++ code still part of 1.5 release?
On Fri, May 17, 2013 at 7:26 AM, Adam Fuchs wrote: > Folks, > > Sorry to be late to the party, but did we come to a consensus on this? > Seems like we still have opinions both ways as to whether the cpp code > should be packaged with the binary distribution. I would argue that cpp > code is a special case, since the build is so platform dependent. It's > generally hard to distribute the right .so files to cover all platforms, > and we have run into many cases in practice where the native maps don't > work out of the box. While downloading the source and untarring it over the > same directory is not too much extra work, I'm neutral on whether the source files should be included in the binary artifacts. However, I wanted to point out that it sounds like untarring the source over binaries is not the recommended procedure. So what is the recommended procedure? Untar the source, navigate to the c++ directory, build, and drop the resulting .so file into an existing binary installation? Or just build your own binary tarball from source? Billie it seems like the only argument > not to package the native source code with the binary distribution is a > dogmatic one. Are there any practical reasons why it would be bad to add > the cpp file to the bin distribution? > > Adam > > > > > On Mon, May 13, 2013 at 10:48 PM, Eric Newton > wrote: > > > Rumor has it that one of the core developers is irrationally hostile to > > perl. > > > > And octal. > > > > And xml. > > > > He's just old and cranky. > > > > -Eric > > > > > > On Mon, May 13, 2013 at 5:29 PM, David Medinets < > david.medin...@gmail.com > > >wrote: > > > > > How come perl is getting no love? > > > > > > > > > On Mon, May 13, 2013 at 10:40 AM, Josh Elser > > wrote: > > > > > > > On 5/12/13 11:45 PM, Christopher wrote: > > > > > > > >> 1) we don't need to include java bindings for the proxy; compiled > > > >> versions are already in the proxy jar, > > > >> 2) not all packagers will even have installed thrift with the > ability > > > >> to produce ruby and python bindings, > > > >> 3) these may or may not be helpful to any particular end user > (though > > > >> it's probably safe to assume ruby and python will be the most > common), > > > >> 4) we're not including the proxy.thrift file, which is perhaps the > > > >> most important file for the proxy, and including it should be > > > >> sufficient. > > > >> > > > >> > > > >> 1)That works. I should've caught that when I was in the proxy last > > and > > > I > > > > didn't.Thanks for that. > > > > 2) Do you mean packagers as in people who might make an official > > release? > > > > I would think these are the only people that "really" matter, and > thus > > I > > > > would expect them to be able to build a full distributionthat include > > > these > > > > bindings. It might be nice to be able to create a packaging for each > > > > language (gem, egg, etc); but until we have some sort of packaging, > I'd > > > > really like to see theruby and pythonsources included even in the > > binary > > > > dist. > > > > 3)True, but I'd rather set the bar as low as possible for people who > > just > > > > want to play around in a scripting language with Accumulo. > > > > 4) Definitely want to make sure it's included. > > > > > > > > Does anyone have an opinion on other languages that thrift supports > > that > > > > we should also create bindings for? I concur with your opinion on > Ruby > > > and > > > > Python, but I wonder if there's something else that people would also > > > like. > > > > > > > > > >
Re: Is C++ code still part of 1.5 release?
Adam, I didn't make any changes on this, because there were only a few opinions, and it didn't seem like there was a consensus. I can make this change, though, if a consensus is established. It's very small, and easy to do. Billie, any of those options would work. I'm not sure we need to recommend a particular one over the other, as long as users know how to get there. An option that Keith and I were discussing is possibly packaging against glibc-2.5 by default, which should reduce the impact on people using RHEL/CentOS 5, but should still work for RHEL/CentOS 6 or anything newer (though they may have to install compat-glibc-2.5). I'm not sure the appropriate modifications to make to get this to work, though. -- Christopher L Tubbs II http://gravatar.com/ctubbsii On Fri, May 17, 2013 at 10:49 AM, Billie Rinaldi wrote: > On Fri, May 17, 2013 at 7:26 AM, Adam Fuchs wrote: > >> Folks, >> >> Sorry to be late to the party, but did we come to a consensus on this? >> Seems like we still have opinions both ways as to whether the cpp code >> should be packaged with the binary distribution. I would argue that cpp >> code is a special case, since the build is so platform dependent. It's >> generally hard to distribute the right .so files to cover all platforms, >> and we have run into many cases in practice where the native maps don't >> work out of the box. While downloading the source and untarring it over the >> same directory is not too much extra work, > > > I'm neutral on whether the source files should be included in the binary > artifacts. However, I wanted to point out that it sounds like untarring > the source over binaries is not the recommended procedure. So what is the > recommended procedure? Untar the source, navigate to the c++ directory, > build, and drop the resulting .so file into an existing binary > installation? Or just build your own binary tarball from source? > > Billie > > > it seems like the only argument >> not to package the native source code with the binary distribution is a >> dogmatic one. Are there any practical reasons why it would be bad to add >> the cpp file to the bin distribution? >> > >> Adam >> >> >> >> >> On Mon, May 13, 2013 at 10:48 PM, Eric Newton >> wrote: >> >> > Rumor has it that one of the core developers is irrationally hostile to >> > perl. >> > >> > And octal. >> > >> > And xml. >> > >> > He's just old and cranky. >> > >> > -Eric >> > >> > >> > On Mon, May 13, 2013 at 5:29 PM, David Medinets < >> david.medin...@gmail.com >> > >wrote: >> > >> > > How come perl is getting no love? >> > > >> > > >> > > On Mon, May 13, 2013 at 10:40 AM, Josh Elser >> > wrote: >> > > >> > > > On 5/12/13 11:45 PM, Christopher wrote: >> > > > >> > > >> 1) we don't need to include java bindings for the proxy; compiled >> > > >> versions are already in the proxy jar, >> > > >> 2) not all packagers will even have installed thrift with the >> ability >> > > >> to produce ruby and python bindings, >> > > >> 3) these may or may not be helpful to any particular end user >> (though >> > > >> it's probably safe to assume ruby and python will be the most >> common), >> > > >> 4) we're not including the proxy.thrift file, which is perhaps the >> > > >> most important file for the proxy, and including it should be >> > > >> sufficient. >> > > >> >> > > >> >> > > >> 1)That works. I should've caught that when I was in the proxy last >> > and >> > > I >> > > > didn't.Thanks for that. >> > > > 2) Do you mean packagers as in people who might make an official >> > release? >> > > > I would think these are the only people that "really" matter, and >> thus >> > I >> > > > would expect them to be able to build a full distributionthat include >> > > these >> > > > bindings. It might be nice to be able to create a packaging for each >> > > > language (gem, egg, etc); but until we have some sort of packaging, >> I'd >> > > > really like to see theruby and pythonsources included even in the >> > binary >> > > > dist. >> > > > 3)True, but I'd rather set the bar as low as possible for people who >> > just >> > > > want to play around in a scripting language with Accumulo. >> > > > 4) Definitely want to make sure it's included. >> > > > >> > > > Does anyone have an opinion on other languages that thrift supports >> > that >> > > > we should also create bindings for? I concur with your opinion on >> Ruby >> > > and >> > > > Python, but I wonder if there's something else that people would also >> > > like. >> > > > >> > > >> > >>
Re: Is C++ code still part of 1.5 release?
Chris, I like the idea of including the most widely used library, but empirical evidence tells me that roughly half of the users of Accumulo will still need to compile/recompile to get native map support. There is no reason not to make that as easy as possible by including the cpp code in the -bin.tar.gz -- at least I haven't heard a reason not to do that yet. Adam On Fri, May 17, 2013 at 11:53 AM, Christopher wrote: > Adam, I didn't make any changes on this, because there were only a few > opinions, and it didn't seem like there was a consensus. I can make > this change, though, if a consensus is established. It's very small, > and easy to do. > > Billie, any of those options would work. I'm not sure we need to > recommend a particular one over the other, as long as users know how > to get there. > > An option that Keith and I were discussing is possibly packaging > against glibc-2.5 by default, which should reduce the impact on people > using RHEL/CentOS 5, but should still work for RHEL/CentOS 6 or > anything newer (though they may have to install compat-glibc-2.5). I'm > not sure the appropriate modifications to make to get this to work, > though. > > -- > Christopher L Tubbs II > http://gravatar.com/ctubbsii > > > On Fri, May 17, 2013 at 10:49 AM, Billie Rinaldi > wrote: > > On Fri, May 17, 2013 at 7:26 AM, Adam Fuchs wrote: > > > >> Folks, > >> > >> Sorry to be late to the party, but did we come to a consensus on this? > >> Seems like we still have opinions both ways as to whether the cpp code > >> should be packaged with the binary distribution. I would argue that cpp > >> code is a special case, since the build is so platform dependent. It's > >> generally hard to distribute the right .so files to cover all platforms, > >> and we have run into many cases in practice where the native maps don't > >> work out of the box. While downloading the source and untarring it over > the > >> same directory is not too much extra work, > > > > > > I'm neutral on whether the source files should be included in the binary > > artifacts. However, I wanted to point out that it sounds like untarring > > the source over binaries is not the recommended procedure. So what is > the > > recommended procedure? Untar the source, navigate to the c++ directory, > > build, and drop the resulting .so file into an existing binary > > installation? Or just build your own binary tarball from source? > > > > Billie > > > > > > it seems like the only argument > >> not to package the native source code with the binary distribution is a > >> dogmatic one. Are there any practical reasons why it would be bad to add > >> the cpp file to the bin distribution? > >> > > > >> Adam > >> > >> > >> > >> > >> On Mon, May 13, 2013 at 10:48 PM, Eric Newton > >> wrote: > >> > >> > Rumor has it that one of the core developers is irrationally hostile > to > >> > perl. > >> > > >> > And octal. > >> > > >> > And xml. > >> > > >> > He's just old and cranky. > >> > > >> > -Eric > >> > > >> > > >> > On Mon, May 13, 2013 at 5:29 PM, David Medinets < > >> david.medin...@gmail.com > >> > >wrote: > >> > > >> > > How come perl is getting no love? > >> > > > >> > > > >> > > On Mon, May 13, 2013 at 10:40 AM, Josh Elser > >> > wrote: > >> > > > >> > > > On 5/12/13 11:45 PM, Christopher wrote: > >> > > > > >> > > >> 1) we don't need to include java bindings for the proxy; compiled > >> > > >> versions are already in the proxy jar, > >> > > >> 2) not all packagers will even have installed thrift with the > >> ability > >> > > >> to produce ruby and python bindings, > >> > > >> 3) these may or may not be helpful to any particular end user > >> (though > >> > > >> it's probably safe to assume ruby and python will be the most > >> common), > >> > > >> 4) we're not including the proxy.thrift file, which is perhaps > the > >> > > >> most important file for the proxy, and including it should be > >> > > >> sufficient. > >> > > >> > >> > > >> > >> > > >> 1)That works. I should've caught that when I was in the proxy > last > >> > and > >> > > I > >> > > > didn't.Thanks for that. > >> > > > 2) Do you mean packagers as in people who might make an official > >> > release? > >> > > > I would think these are the only people that "really" matter, and > >> thus > >> > I > >> > > > would expect them to be able to build a full distributionthat > include > >> > > these > >> > > > bindings. It might be nice to be able to create a packaging for > each > >> > > > language (gem, egg, etc); but until we have some sort of > packaging, > >> I'd > >> > > > really like to see theruby and pythonsources included even in the > >> > binary > >> > > > dist. > >> > > > 3)True, but I'd rather set the bar as low as possible for people > who > >> > just > >> > > > want to play around in a scripting language with Accumulo. > >> > > > 4) Definitely want to make sure it's included. > >> > > > > >> > > > Does anyone have an opinion on other languages that thrift > supports > >> > that > >>
Re: Is C++ code still part of 1.5 release?
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: On 5/17/13 2:04 PM, Adam Fuchs wrote: Chris, I like the idea of including the most widely used library, but empirical evidence tells me that roughly half of the users of Accumulo will still need to compile/recompile to get native map support. There is no reason not to make that as easy as possible by including the cpp code in the -bin.tar.gz -- at least I haven't heard a reason not to do that yet. Adam On Fri, May 17, 2013 at 11:53 AM, Christopher wrote: Adam, I didn't make any changes on this, because there were only a few opinions, and it didn't seem like there was a consensus. I can make this change, though, if a consensus is established. It's very small, and easy to do. Billie, any of those options would work. I'm not sure we need to recommend a particular one over the other, as long as users know how to get there. An option that Keith and I were discussing is possibly packaging against glibc-2.5 by default, which should reduce the impact on people using RHEL/CentOS 5, but should still work for RHEL/CentOS 6 or anything newer (though they may have to install compat-glibc-2.5). I'm not sure the appropriate modifications to make to get this to work, though. -- Christopher L Tubbs II http://gravatar.com/ctubbsii On Fri, May 17, 2013 at 10:49 AM, Billie Rinaldi wrote: On Fri, May 17, 2013 at 7:26 AM, Adam Fuchs wrote: Folks, Sorry to be late to the party, but did we come to a consensus on this? Seems like we still have opinions both ways as to whether the cpp code should be packaged with the binary distribution. I would argue that cpp code is a special case, since the build is so platform dependent. It's generally hard to distribute the right .so files to cover all platforms, and we have run into many cases in practice where the native maps don't work out of the box. While downloading the source and untarring it over the same directory is not too much extra work, I'm neutral on whether the source files should be included in the binary artifacts. However, I wanted to point out that it sounds like untarring the source over binaries is not the recommended procedure. So what is the recommended procedure? Untar the source, navigate to the c++ directory, build, and drop the resulting .so file into an existing binary installation? Or just build your own binary tarball from source? Billie it seems like the only argument not to package the native source code with the binary distribution is a dogmatic one. Are there any practical reasons why it would be bad to add the cpp file to the bin distribution? Adam On Mon, May 13, 2013 at 10:48 PM, Eric Newton wrote: Rumor has it that one of the core developers is irrationally hostile to perl. And octal. And xml. He's just old and cranky. -Eric On Mon, May 13, 2013 at 5:29 PM, David Medinets < david.medin...@gmail.com wrote: How come perl is getting no love? On Mon, May 13, 2013 at 10:40 AM, Josh Elser wrote: On 5/12/13 11:45 PM, Christopher wrote: 1) we don't need to include java bindings for the proxy; compiled versions are already in the proxy jar, 2) not all packagers will even have installed thrift with the ability to produce ruby and python bindings, 3) these may or may not be helpful to any particular end user (though it's probably safe to assume ruby and python will be the most common), 4) we're not including the proxy.thrift file, which is perhaps the most important file for the proxy, and including it should be sufficient. 1)That works. I should've caught that when I was in the proxy last and I didn't.Thanks for that. 2) Do you mean packagers as in people who might make an official release? I would think these are the only people that "really" matter, and thus I would expect them to be able to build a full distributionthat include these bindings. It might be nice to be able to create a packaging for each language (gem, egg, etc); but until we have some sort of packaging, I'd really like to see theruby and pythonsources included even in the binary dist. 3)True, but I'd rather set the bar as low as possible for people who just want to play around in a scripting language with Accumulo. 4) Definitely want to make sure it's included. Does anyone have an opinion on other languages that thrift supports
Re: Is C++ code still part of 1.5 release?
Well, the reason not to, was to draw a line in the sand between what it means to have a "source" release, and a "binary" release. But, I agree that there's probably sufficient reason to include them despite crossing that line, and it seems the consensus is going that way. -- Christopher L Tubbs II http://gravatar.com/ctubbsii On Fri, May 17, 2013 at 2:04 PM, Adam Fuchs wrote: > Chris, > > I like the idea of including the most widely used library, but empirical > evidence tells me that roughly half of the users of Accumulo will still > need to compile/recompile to get native map support. There is no reason not > to make that as easy as possible by including the cpp code in the > -bin.tar.gz -- at least I haven't heard a reason not to do that yet. > > Adam > > > > On Fri, May 17, 2013 at 11:53 AM, Christopher wrote: > >> Adam, I didn't make any changes on this, because there were only a few >> opinions, and it didn't seem like there was a consensus. I can make >> this change, though, if a consensus is established. It's very small, >> and easy to do. >> >> Billie, any of those options would work. I'm not sure we need to >> recommend a particular one over the other, as long as users know how >> to get there. >> >> An option that Keith and I were discussing is possibly packaging >> against glibc-2.5 by default, which should reduce the impact on people >> using RHEL/CentOS 5, but should still work for RHEL/CentOS 6 or >> anything newer (though they may have to install compat-glibc-2.5). I'm >> not sure the appropriate modifications to make to get this to work, >> though. >> >> -- >> Christopher L Tubbs II >> http://gravatar.com/ctubbsii >> >> >> On Fri, May 17, 2013 at 10:49 AM, Billie Rinaldi >> wrote: >> > On Fri, May 17, 2013 at 7:26 AM, Adam Fuchs wrote: >> > >> >> Folks, >> >> >> >> Sorry to be late to the party, but did we come to a consensus on this? >> >> Seems like we still have opinions both ways as to whether the cpp code >> >> should be packaged with the binary distribution. I would argue that cpp >> >> code is a special case, since the build is so platform dependent. It's >> >> generally hard to distribute the right .so files to cover all platforms, >> >> and we have run into many cases in practice where the native maps don't >> >> work out of the box. While downloading the source and untarring it over >> the >> >> same directory is not too much extra work, >> > >> > >> > I'm neutral on whether the source files should be included in the binary >> > artifacts. However, I wanted to point out that it sounds like untarring >> > the source over binaries is not the recommended procedure. So what is >> the >> > recommended procedure? Untar the source, navigate to the c++ directory, >> > build, and drop the resulting .so file into an existing binary >> > installation? Or just build your own binary tarball from source? >> > >> > Billie >> > >> > >> > it seems like the only argument >> >> not to package the native source code with the binary distribution is a >> >> dogmatic one. Are there any practical reasons why it would be bad to add >> >> the cpp file to the bin distribution? >> >> >> > >> >> Adam >> >> >> >> >> >> >> >> >> >> On Mon, May 13, 2013 at 10:48 PM, Eric Newton >> >> wrote: >> >> >> >> > Rumor has it that one of the core developers is irrationally hostile >> to >> >> > perl. >> >> > >> >> > And octal. >> >> > >> >> > And xml. >> >> > >> >> > He's just old and cranky. >> >> > >> >> > -Eric >> >> > >> >> > >> >> > On Mon, May 13, 2013 at 5:29 PM, David Medinets < >> >> david.medin...@gmail.com >> >> > >wrote: >> >> > >> >> > > How come perl is getting no love? >> >> > > >> >> > > >> >> > > On Mon, May 13, 2013 at 10:40 AM, Josh Elser >> >> > wrote: >> >> > > >> >> > > > On 5/12/13 11:45 PM, Christopher wrote: >> >> > > > >> >> > > >> 1) we don't need to include java bindings for the proxy; compiled >> >> > > >> versions are already in the proxy jar, >> >> > > >> 2) not all packagers will even have installed thrift with the >> >> ability >> >> > > >> to produce ruby and python bindings, >> >> > > >> 3) these may or may not be helpful to any particular end user >> >> (though >> >> > > >> it's probably safe to assume ruby and python will be the most >> >> common), >> >> > > >> 4) we're not including the proxy.thrift file, which is perhaps >> the >> >> > > >> most important file for the proxy, and including it should be >> >> > > >> sufficient. >> >> > > >> >> >> > > >> >> >> > > >> 1)That works. I should've caught that when I was in the proxy >> last >> >> > and >> >> > > I >> >> > > > didn't.Thanks for that. >> >> > > > 2) Do you mean packagers as in people who might make an official >> >> > release? >> >> > > > I would think these are the only people that "really" matter, and >> >> thus >> >> > I >> >> > > > would expect them to be able to build a full distributionthat >> include >> >> > > these >> >> > > > bindings. It might be nice to be able to create a packaging for >> each >> >>
Re: Is C++ code still part of 1.5 release?
On Fri, May 17, 2013 at 2:31 PM, Christopher wrote: > Well, the reason not to, was to draw a line in the sand between what > it means to have a "source" release, and a "binary" release. > But, I agree that there's probably sufficient reason to include them > despite crossing that line, and it seems the consensus is going that > way. > Irrespective of where this source code is I am not sure we have good documentation anywhere that outlines how and why native maps should be built. Things work if they are not built or built but fail to load. I will open a ticket for the documentation issue. > -- > Christopher L Tubbs II > http://gravatar.com/ctubbsii > > > On Fri, May 17, 2013 at 2:04 PM, Adam Fuchs wrote: > > Chris, > > > > I like the idea of including the most widely used library, but empirical > > evidence tells me that roughly half of the users of Accumulo will still > > need to compile/recompile to get native map support. There is no reason > not > > to make that as easy as possible by including the cpp code in the > > -bin.tar.gz -- at least I haven't heard a reason not to do that yet. > > > > Adam > > > > > > > > On Fri, May 17, 2013 at 11:53 AM, Christopher > wrote: > > > >> Adam, I didn't make any changes on this, because there were only a few > >> opinions, and it didn't seem like there was a consensus. I can make > >> this change, though, if a consensus is established. It's very small, > >> and easy to do. > >> > >> Billie, any of those options would work. I'm not sure we need to > >> recommend a particular one over the other, as long as users know how > >> to get there. > >> > >> An option that Keith and I were discussing is possibly packaging > >> against glibc-2.5 by default, which should reduce the impact on people > >> using RHEL/CentOS 5, but should still work for RHEL/CentOS 6 or > >> anything newer (though they may have to install compat-glibc-2.5). I'm > >> not sure the appropriate modifications to make to get this to work, > >> though. > >> > >> -- > >> Christopher L Tubbs II > >> http://gravatar.com/ctubbsii > >> > >> > >> On Fri, May 17, 2013 at 10:49 AM, Billie Rinaldi > >> wrote: > >> > On Fri, May 17, 2013 at 7:26 AM, Adam Fuchs > wrote: > >> > > >> >> Folks, > >> >> > >> >> Sorry to be late to the party, but did we come to a consensus on > this? > >> >> Seems like we still have opinions both ways as to whether the cpp > code > >> >> should be packaged with the binary distribution. I would argue that > cpp > >> >> code is a special case, since the build is so platform dependent. > It's > >> >> generally hard to distribute the right .so files to cover all > platforms, > >> >> and we have run into many cases in practice where the native maps > don't > >> >> work out of the box. While downloading the source and untarring it > over > >> the > >> >> same directory is not too much extra work, > >> > > >> > > >> > I'm neutral on whether the source files should be included in the > binary > >> > artifacts. However, I wanted to point out that it sounds like > untarring > >> > the source over binaries is not the recommended procedure. So what is > >> the > >> > recommended procedure? Untar the source, navigate to the c++ > directory, > >> > build, and drop the resulting .so file into an existing binary > >> > installation? Or just build your own binary tarball from source? > >> > > >> > Billie > >> > > >> > > >> > it seems like the only argument > >> >> not to package the native source code with the binary distribution > is a > >> >> dogmatic one. Are there any practical reasons why it would be bad to > add > >> >> the cpp file to the bin distribution? > >> >> > >> > > >> >> Adam > >> >> > >> >> > >> >> > >> >> > >> >> On Mon, May 13, 2013 at 10:48 PM, Eric Newton > > >> >> wrote: > >> >> > >> >> > Rumor has it that one of the core developers is irrationally > hostile > >> to > >> >> > perl. > >> >> > > >> >> > And octal. > >> >> > > >> >> > And xml. > >> >> > > >> >> > He's just old and cranky. > >> >> > > >> >> > -Eric > >> >> > > >> >> > > >> >> > On Mon, May 13, 2013 at 5:29 PM, David Medinets < > >> >> david.medin...@gmail.com > >> >> > >wrote: > >> >> > > >> >> > > How come perl is getting no love? > >> >> > > > >> >> > > > >> >> > > On Mon, May 13, 2013 at 10:40 AM, Josh Elser < > josh.el...@gmail.com> > >> >> > wrote: > >> >> > > > >> >> > > > On 5/12/13 11:45 PM, Christopher wrote: > >> >> > > > > >> >> > > >> 1) we don't need to include java bindings for the proxy; > compiled > >> >> > > >> versions are already in the proxy jar, > >> >> > > >> 2) not all packagers will even have installed thrift with the > >> >> ability > >> >> > > >> to produce ruby and python bindings, > >> >> > > >> 3) these may or may not be helpful to any particular end user > >> >> (though > >> >> > > >> it's probably safe to assume ruby and python will be the most > >> >> common), > >> >> > > >> 4) we're not including the proxy.thrift file, which is perhaps > >> the > >> >> > > >> most importan
Re: Is C++ code still part of 1.5 release?
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 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: > > > On 5/17/13 2:04 PM, Adam Fuchs wrote: > >> Chris, >> >> I like the idea of including the most widely used library, but empirical >> evidence tells me that roughly half of the users of Accumulo will still >> need to compile/recompile to get native map support. There is no reason >> not >> to make that as easy as possible by including the cpp code in the >> -bin.tar.gz -- at least I haven't heard a reason not to do that yet. >> >> Adam >> >> >> >> On Fri, May 17, 2013 at 11:53 AM, Christopher >> wrote: >> >> Adam, I didn't make any changes on this, because there were only a few >>> opinions, and it didn't seem like there was a consensus. I can make >>> this change, though, if a consensus is established. It's very small, >>> and easy to do. >>> >>> Billie, any of those options would work. I'm not sure we need to >>> recommend a particular one over the other, as long as users know how >>> to get there. >>> >>> An option that Keith and I were discussing is possibly packaging >>> against glibc-2.5 by default, which should reduce the impact on people >>> using RHEL/CentOS 5, but should still work for RHEL/CentOS 6 or >>> anything newer (though they may have to install compat-glibc-2.5). I'm >>> not sure the appropriate modifications to make to get this to work, >>> though. >>> >>> -- >>> Christopher L Tubbs II >>> http://gravatar.com/ctubbsii >>> >>> >>> On Fri, May 17, 2013 at 10:49 AM, Billie Rinaldi >>> wrote: >>> On Fri, May 17, 2013 at 7:26 AM, Adam Fuchs wrote: Folks, > > Sorry to be late to the party, but did we come to a consensus on this? > Seems like we still have opinions both ways as to whether the cpp code > should be packaged with the binary distribution. I would argue that cpp > code is a special case, since the build is so platform dependent. It's > generally hard to distribute the right .so files to cover all > platforms, > and we have run into many cases in practice where the native maps don't > work out of the box. While downloading the source and untarring it over > the >>> same directory is not too much extra work, > I'm neutral on whether the source files should be included in the binary artifacts. However, I wanted to point out that it sounds like untarring the source over binaries is not the recommended procedure. So what is >>> the >>> recommended procedure? Untar the source, navigate to the c++ directory, build, and drop the resulting .so file into an existing binary installation? Or just build your own binary tarball from source? Billie it seems like the only argument > not to package the native source code with the binary distribution is a > dogmatic one. Are there any practical reasons why it would be bad to > add > the cpp file to the bin distribution? > > Adam > > > > > On Mon, May 13, 2013 at 10:48 PM, Eric Newton > wrote: > > Rumor has it that one of the core developers is irrationally hostile >> > to >>> perl. >> >> And octal. >> >> And xml. >> >> He's just old and cranky. >> >> -Eric >> >> >> On Mon, May 13, 2013 at 5:29 PM, David Medinets < >> > david.medin...@gmail.com > >> wrote: >>> >> >> How come perl is getting no love? >>> >>> >>> On Mon, May 13, 2013 at 10:40 AM, Josh Elser >>> >> wrote: >> >>> >>> On 5/12/13 11:45 PM, Christopher wrote: 1) we don't need to include java bindings for the proxy; compiled > versions are already in the proxy jar, > 2) not all packagers will even have installed thrift with the > ability > >> to produce ruby and python bindings, > 3) these may or may not be helpful to any parti
Re: Is C++ code still part of 1.5 release?
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.cl...@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 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: > > > > > > On 5/17/13 2:04 PM, Adam Fuchs wrote: > > > >> Chris, > >> > >> I like the idea of including the most widely used library, but empirical > >> evidence tells me that roughly half of the users of Accumulo will still > >> need to compile/recompile to get native map support. There is no reason > >> not > >> to make that as easy as possible by including the cpp code in the > >> -bin.tar.gz -- at least I haven't heard a reason not to do that yet. > >> > >> Adam > >> > >> > >> > >> On Fri, May 17, 2013 at 11:53 AM, Christopher > >> wrote: > >> > >> Adam, I didn't make any changes on this, because there were only a few > >>> opinions, and it didn't seem like there was a consensus. I can make > >>> this change, though, if a consensus is established. It's very small, > >>> and easy to do. > >>> > >>> Billie, any of those options would work. I'm not sure we need to > >>> recommend a particular one over the other, as long as users know how > >>> to get there. > >>> > >>> An option that Keith and I were discussing is possibly packaging > >>> against glibc-2.5 by default, which should reduce the impact on people > >>> using RHEL/CentOS 5, but should still work for RHEL/CentOS 6 or > >>> anything newer (though they may have to install compat-glibc-2.5). I'm > >>> not sure the appropriate modifications to make to get this to work, > >>> though. > >>> > >>> -- > >>> Christopher L Tubbs II > >>> http://gravatar.com/ctubbsii > >>> > >>> > >>> On Fri, May 17, 2013 at 10:49 AM, Billie Rinaldi > >>> wrote: > >>> > On Fri, May 17, 2013 at 7:26 AM, Adam Fuchs > wrote: > > Folks, > > > > Sorry to be late to the party, but did we come to a consensus on > this? > > Seems like we still have opinions both ways as to whether the cpp > code > > should be packaged with the binary distribution. I would argue that > cpp > > code is a special case, since the build is so platform dependent. > It's > > generally hard to distribute the right .so files to cover all > > platforms, > > and we have run into many cases in practice where the native maps > don't > > work out of the box. While downloading the source and untarring it > over > > > the > >>> > same directory is not too much extra work, > > > > > I'm neutral on whether the source files should be included in the > binary > artifacts. However, I wanted to point out that it sounds like > untarring > the source over binaries is not the recommended procedure. So what is > > >>> the > >>> > recommended procedure? Untar the source, navigate to the c++ > directory, > build, and drop the resulting .so file into an existing binary > installation? Or just build your own binary tarball from source? > > Billie > > > it seems like the only argument > > > not to package the native source code with the binary distribution > is a > > dogmatic one. Are there any practical reasons why it would be bad to > > add > > the cpp file to the bin distribution? > > > > > Adam > > > >>>
Re: Is C++ code still part of 1.5 release?
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 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.cl...@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 > 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: > > > > > > > > > On 5/17/13 2:04 PM, Adam Fuchs wrote: > > > > > >> Chris, > > >> > > >> I like the idea of including the most widely used library, but > empirical > > >> evidence tells me that roughly half of the users of Accumulo will > still > > >> need to compile/recompile to get native map support. There is no > reason > > >> not > > >> to make that as easy as possible by including the cpp code in the > > >> -bin.tar.gz -- at least I haven't heard a reason not to do that yet. > > >> > > >> Adam > > >> > > >> > > >> > > >> On Fri, May 17, 2013 at 11:53 AM, Christopher > > >> wrote: > > >> > > >> Adam, I didn't make any changes on this, because there were only a > few > > >>> opinions, and it didn't seem like there was a consensus. I can make > > >>> this change, though, if a consensus is established. It's very small, > > >>> and easy to do. > > >>> > > >>> Billie, any of those options would work. I'm not sure we need to > > >>> recommend a particular one over the other, as long as users know how > > >>> to get there. > > >>> > > >>> An option that Keith and I were discussing is possibly packaging > > >>> against glibc-2.5 by default, which should reduce the impact on > people > > >>> using RHEL/CentOS 5, but should still work for RHEL/CentOS 6 or > > >>> anything newer (though they may have to install compat-glibc-2.5). > I'm > > >>> not sure the appropriate modifications to make to get this to work, > > >>> though. > > >>> > > >>> -- > > >>> Christopher L Tubbs II > > >>> http://gravatar.com/ctubbsii > > >>> > > >>> > > >>> On Fri, May 17, 2013 at 10:49 AM, Billie Rinaldi > > >>> wrote: > > >>> > > On Fri, May 17, 2013 at 7:26 AM, Adam Fuchs > > wrote: > > > > Folks, > > > > > > Sorry to be late to the party, but did we come to a consensus on > > this? > > > Seems like we still have opinions both ways as to whether the cpp > > code > > > should be packaged with the binary distribution. I would argue that > > cpp > > > code is a special case, since the build is so platform dependent. > > It's > > > generally hard to distribute the right .so files to cover all > > > platforms, > > > and we have run into many cases in practice where the native maps > > don't > > > work out of the box. While downloading the source and untarring it > > over > > > > > the > > >>> > > same directory is not too much extra work, > > > > > > > > > I'm neutral on whether the source files should be included in the > > binary > > artifacts. Ho
Re: Is C++ code still part of 1.5 release?
Adam, I agree. As long as a user / system admin has a quick (and well-documented) path to getting the native map where it needs to go in the binary distribution, I think both 1 & 2 are viable. I tend to lean towards #1, for no reason other than that it adds 1 step but is much more maintainable. On Fri, May 17, 2013 at 3:11 PM, Adam Fuchs 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.cl...@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 > 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: > > > > > > > > > On 5/17/13 2:04 PM, Adam Fuchs wrote: > > > > > >> Chris, > > >> > > >> I like the idea of including the most widely used library, but > empirical > > >> evidence tells me that roughly half of the users of Accumulo will > still > > >> need to compile/recompile to get native map support. There is no > reason > > >> not > > >> to make that as easy as possible by including the cpp code in the > > >> -bin.tar.gz -- at least I haven't heard a reason not to do that yet. > > >> > > >> Adam > > >> > > >> > > >> > > >> On Fri, May 17, 2013 at 11:53 AM, Christopher > > >> wrote: > > >> > > >> Adam, I didn't make any changes on this, because there were only a > few > > >>> opinions, and it didn't seem like there was a consensus. I can make > > >>> this change, though, if a consensus is established. It's very small, > > >>> and easy to do. > > >>> > > >>> Billie, any of those options would work. I'm not sure we need to > > >>> recommend a particular one over the other, as long as users know how > > >>> to get there. > > >>> > > >>> An option that Keith and I were discussing is possibly packaging > > >>> against glibc-2.5 by default, which should reduce the impact on > people > > >>> using RHEL/CentOS 5, but should still work for RHEL/CentOS 6 or > > >>> anything newer (though they may have to install compat-glibc-2.5). > I'm > > >>> not sure the appropriate modifications to make to get this to work, > > >>> though. > > >>> > > >>> -- > > >>> Christopher L Tubbs II > > >>> http://gravatar.com/ctubbsii > > >>> > > >>> > > >>> On Fri, May 17, 2013 at 10:49 AM, Billie Rinaldi > > >>> wrote: > > >>> > > On Fri, May 17, 2013 at 7:26 AM, Adam Fuchs > > wrote: > > > > Folks, > > > > > > Sorry to be late to the party, but did we come to a consensus on > > this? > > > Seems like we still have opinions both ways as to whether the cpp > > code > > > should be packaged with the binary distribution. I would argue that > > cpp > > > code is a special case, since the build is so platform dependent. > > It's > > > generally hard to distribute the right .so files to cover all > > > platforms, > > > and we have run into many cases in practice where the native maps > > don't > > > work out of the box. While downloading the source and untarring it > > over > > > > > the > > >>> > > same directory is not too much extra work, > > > > > > > > > I'm neutral on whether the source files should be included in the > > binary > > artifacts. However, I wanted to point out that it sounds like > > untarring > > the source over binaries is not the recommended pro
Re: Is C++ code still part of 1.5 release?
I don't think ease of work is a factor, since doing nothing is certainly easier than something. I'd really just prefer consistency and convention in what we do. If we label something as binary, it is binary. If we label something as source, it is source. That's certainly a lower risk long term strategy than, "it felt good at the time." On Fri, May 17, 2013 at 3:19 PM, Corey Nolet wrote: > Adam, I agree. As long as a user / system admin has a quick (and > well-documented) path to getting the native map where it needs to go in the > binary distribution, I think both 1 & 2 are viable. I tend to lean towards > #1, for no reason other than that it adds 1 step but is much more > maintainable. > > > On Fri, May 17, 2013 at 3:11 PM, Adam Fuchs 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.cl...@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 > > 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: > > > > > > > > > > > > On 5/17/13 2:04 PM, Adam Fuchs wrote: > > > > > > > >> Chris, > > > >> > > > >> I like the idea of including the most widely used library, but > > empirical > > > >> evidence tells me that roughly half of the users of Accumulo will > > still > > > >> need to compile/recompile to get native map support. There is no > > reason > > > >> not > > > >> to make that as easy as possible by including the cpp code in the > > > >> -bin.tar.gz -- at least I haven't heard a reason not to do that yet. > > > >> > > > >> Adam > > > >> > > > >> > > > >> > > > >> On Fri, May 17, 2013 at 11:53 AM, Christopher > > > >> wrote: > > > >> > > > >> Adam, I didn't make any changes on this, because there were only a > > few > > > >>> opinions, and it didn't seem like there was a consensus. I can make > > > >>> this change, though, if a consensus is established. It's very > small, > > > >>> and easy to do. > > > >>> > > > >>> Billie, any of those options would work. I'm not sure we need to > > > >>> recommend a particular one over the other, as long as users know > how > > > >>> to get there. > > > >>> > > > >>> An option that Keith and I were discussing is possibly packaging > > > >>> against glibc-2.5 by default, which should reduce the impact on > > people > > > >>> using RHEL/CentOS 5, but should still work for RHEL/CentOS 6 or > > > >>> anything newer (though they may have to install compat-glibc-2.5). > > I'm > > > >>> not sure the appropriate modifications to make to get this to work, > > > >>> though. > > > >>> > > > >>> -- > > > >>> Christopher L Tubbs II > > > >>> http://gravatar.com/ctubbsii > > > >>> > > > >>> > > > >>> On Fri, May 17, 2013 at 10:49 AM, Billie Rinaldi > > > >>> wrote: > > > >>> > > > On Fri, May 17, 2013 at 7:26 AM, Adam Fuchs > > > wrote: > > > > > > Folks, > > > > > > > > Sorry to be late to the party, but did we come to a consensus on > > > this? > > > > Seems like we still have opinions both ways as to whether the cpp > > > code > > > > should be packaged with the binary distribution. I would argue > that > > > cpp > > > > code is a special case, sinc
Re: Is C++ code still part of 1.5 release?
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 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.cl...@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 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:
Re: Is C++ code still part of 1.5 release?
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" 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 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.cl...@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 >>> 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: > > >
Re: Is C++ code still part of 1.5 release?
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 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" 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 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.cl...@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 > > >>> 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: > > > > > > >
Re: Is C++ code still part of 1.5 release?
It's also worthwhile to note, again, that you don't *need* that native map to run Accumulo. I agree with your point on the suffix. If we can't come to something where everyone is happy, we don't make two distributions. To give some 3rd party ASF context -- Apache Hadoop, in their bin distribution, includes "no" source (which includes Java and C++). In their src distribution, you get both the compiled binaries and the source. Only caveat with that are some headers that I think you need to run pipes, but that's irrelevant to this discussion. On 5/17/13 4:00 PM, Michael Berman 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 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" 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 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.cl...@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 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:
Re: Is C++ code still part of 1.5 release?
On Fri, May 17, 2013 at 12:35 PM, Josh Elser 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 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.cl...@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 >>> 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: > > >
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 wrote: > On Fri, May 17, 2013 at 12:35 PM, Josh Elser 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 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.cl...@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 > > >>> 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 > >
Re: Is C++ code still part of 1.5 release?
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. 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 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 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" 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 > 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.cl...@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 > > > > >>> 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 > >
Re: Is C++ code still part of 1.5 release?
Just a quick weigh in here: As a user of open source software, I have no expectation that a file called "-bin" have zero source code in it. What I expect is that I should be able to download a thing called "-bin", untar it and run it without having to do a compile. To make it run *fast*, I would expect to do "something else" where that might be compiling something or configuring something. I would *not* expect that a *common* way to make something run fast be included in something *else* that I have to download. That just makes me think that the people that put this "-bin" together for me wanted me to jump through extra hoops to make it run right. To William's point about seeing a Makefile and thinking I have to build something to make it work: I don't think the Makefile is at the top level directory, right? Given that, I might never see it unless I go poking around for it (or find instructions that direct me to it). - Mike On Fri, May 17, 2013 at 5:12 PM, Adam Fuchs 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. > > 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 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 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" 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 > > 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
Re: Is C++ code still part of 1.5 release?
The Makefile is nowhere at the moment :) But the point remains is that someone in this thread has already confused an optional component as necessary. I also wouldn't want to convey the idea that it doesn't run "right" out of the box either. I'm sure Christopher would be happy on a resolution. If we want the super tar, that's fine, but it seems there's demand for a binary release. Personally, I'm not averse to total distribution size, but I want whatever someone downloads to be labeled properly and they get what they expected to get. On Fri, May 17, 2013 at 5:19 PM, Michael Allen wrote: > Just a quick weigh in here: > > As a user of open source software, I have no expectation that a file called > "-bin" have zero source code in it. What I expect is that I should be able > to download a thing called "-bin", untar it and run it without having to do > a compile. To make it run *fast*, I would expect to do "something else" > where that might be compiling something or configuring something. I would > *not* expect that a *common* way to make something run fast be included in > something *else* that I have to download. That just makes me think that > the people that put this "-bin" together for me wanted me to jump through > extra hoops to make it run right. > > To William's point about seeing a Makefile and thinking I have to build > something to make it work: I don't think the Makefile is at the top level > directory, right? Given that, I might never see it unless I go poking > around for it (or find instructions that direct me to it). > > - Mike > > > On Fri, May 17, 2013 at 5:12 PM, Adam Fuchs 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. > > > > 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 > 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 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" 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
Re: Is C++ code still part of 1.5 release?
I think the point here is that *a* copy of the compiled native maps *is*
included. The point here is that the compiled library is now
platform/architecture dependent, and, how far should we go to make
things easier?
Adam, I don't recall seeing "dramatically less emails" on our lists, so
I would have to disagree with you on that point. Christopher does bring
up a good point on this subject: "what does -dist even mean?". Should it
work on linux-amd64? Linux-x86? OSX-intel? Windows-x64? OSX-ppc? Sparc?
In the interest of actually making something positive come out of this
that satisfies all parties, I move that we make an
${artifact}-${version}-src.tar.gz and
${artifact}-${version}-something.tar.gz. '-src' contains the expected
ASF source release, and '-something' contains the source and compiled
artifacts (platform specific and not). If '-something' == '-dist',
that's fine. In fact, I really don't care in that regard. If someone has
a better suggestion than '-dist' which is succinct and more descriptive,
I'd be happy to use that suggestion instead.
If I missed some caveat here, I apologize.
On 5/17/13 5:19 PM, Michael Allen wrote:
Just a quick weigh in here:
As a user of open source software, I have no expectation that a file called
"-bin" have zero source code in it. What I expect is that I should be able
to download a thing called "-bin", untar it and run it without having to do
a compile. To make it run *fast*, I would expect to do "something else"
where that might be compiling something or configuring something. I would
*not* expect that a *common* way to make something run fast be included in
something *else* that I have to download. That just makes me think that
the people that put this "-bin" together for me wanted me to jump through
extra hoops to make it run right.
To William's point about seeing a Makefile and thinking I have to build
something to make it work: I don't think the Makefile is at the top level
directory, right? Given that, I might never see it unless I go poking
around for it (or find instructions that direct me to it).
- Mike
On Fri, May 17, 2013 at 5:12 PM, Adam Fuchs 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.
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 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 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" 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 agai
Re: Is C++ code still part of 1.5 release?
The expectation that downloading it, untar'ing it, and running it without compiling *does* (or should... that's what we're supposed to be reviewing) work with the -bin that was produced. What you're expecting to also work is one particular add-on feature that requires compilation from source to work, as an optimization. The -bin that has been produced is arch-dependent, and provided for x86_64, el6-compatible convenience. There is *nothing* to stop anybody from rolling another similar -bin package that is for a different architecture or target OS. Now, perhaps we should seriously consider simply omitting the native maps add-on from the binary package entirely, so that our binary packaging is noarch, and providing separate arch-dependent binary distributions of those that need it (this is actually something I had hoped to accomplish for 1.6). -- Christopher L Tubbs II http://gravatar.com/ctubbsii On Fri, May 17, 2013 at 5:19 PM, Michael Allen wrote: > Just a quick weigh in here: > > As a user of open source software, I have no expectation that a file called > "-bin" have zero source code in it. What I expect is that I should be able > to download a thing called "-bin", untar it and run it without having to do > a compile. To make it run *fast*, I would expect to do "something else" > where that might be compiling something or configuring something. I would > *not* expect that a *common* way to make something run fast be included in > something *else* that I have to download. That just makes me think that > the people that put this "-bin" together for me wanted me to jump through > extra hoops to make it run right. > > To William's point about seeing a Makefile and thinking I have to build > something to make it work: I don't think the Makefile is at the top level > directory, right? Given that, I might never see it unless I go poking > around for it (or find instructions that direct me to it). > > - Mike > > > On Fri, May 17, 2013 at 5:12 PM, Adam Fuchs 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. >> >> 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 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 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" 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 libr
Re: Is C++ code still part of 1.5 release?
On May 17, 2013 5:13 PM, "Adam Fuchs" 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 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 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" 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 > > 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.cl...@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, M
RE: Is C++ code still part of 1.5 release?
how about let's get the show on the road and produce any build. it is not grandmas downloading this thing it is gadget heads. Sent from my Android Sorry if brief
Re: Is C++ code still part of 1.5 release?
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 wrote: > On May 17, 2013 5:13 PM, "Adam Fuchs" 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 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 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" 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 >> > 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 >
Re: Is C++ code still part of 1.5 release?
Good link Billie. Sent from my Motorola ATRIX™ 4G on AT&T -Original message- From: Billie Rinaldi To: dev@accumulo.apache.org Sent: Fri, May 17, 2013 21:39:44 GMT+00:00 Subject: Re: Is C++ code still part of 1.5 release? On May 17, 2013 5:13 PM, "Adam Fuchs" 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 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 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" 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 > > 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 le
Re: Is C++ code still part of 1.5 release?
I stand corrected. Thanks for the link, Billie. Looks like we should also remove the .so file from the -src.tar.gz lest we risk having our project deleted. Adam On Fri, May 17, 2013 at 5:39 PM, Billie Rinaldi wrote: > On May 17, 2013 5:13 PM, "Adam Fuchs" 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 > 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 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" 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 > > > 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.cl...@accumulo.net**> wrote: > > > > >>> > > > > >>> I think of the native maps a
Re: Is C++ code still part of 1.5 release?
Yeah, the inclusion of the binary in the source tarball was an oversight that has been corrected. If you're interested in the details: We require the javadocs to be built aggregately, because we ship them for the monitor. So, we need them already built for the package phase. However, they can't be built until the children are compiled, so we execute similar to: mvn clean compile javadoc:aggregate package -P docs,apache-release,native, etc... This means that the packaging of the source assembly either gets executed after the the binaries have been built, (or, if we override and bind the source assembly to an earlier phase, it gets executed twice) and ends up picking them up (this is a side-effect of what I intend to fix with ACCUMULO-935 (one of the many issues I intend to fix with that ticket)). I have put in a little bit of messiness to get it to work right now (bound to the validate phase to run before everything, and uses exec plugin to mv with --no-clobber flag, so I keep the earlier one). I may have a cleaner workaround in mind, but this is working for now. -- Christopher L Tubbs II http://gravatar.com/ctubbsii On Fri, May 17, 2013 at 10:11 PM, Adam Fuchs wrote: > I stand corrected. Thanks for the link, Billie. Looks like we should also > remove the .so file from the -src.tar.gz lest we risk having our project > deleted. > > Adam > > > > On Fri, May 17, 2013 at 5:39 PM, Billie Rinaldi > wrote: > >> On May 17, 2013 5:13 PM, "Adam Fuchs" 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 >> 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 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" 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
