You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@avro.apache.org by Doug Cutting <cu...@apache.org> on 2010/02/20 01:15:17 UTC
[VOTE] Avro release 1.3.0 (rc 1)
I have created a second candidate build for Avro release 1.3.0.
Please download, test, and vote by 24 February.
http://people.apache.org/~cutting/avro-1.3.0-rc1/
Thanks,
Doug
Re: [VOTE] Avro release 1.3.0 (rc 1)
Posted by Patrick Hunt <ph...@apache.org>.
Doug Cutting wrote:
> Patrick Hunt wrote:
>> I tried installing "yajl-ruby" using gem and that failed as "mkmf" was
>> not available. It seems that there is also a requirement that
>> "ruby-dev" be installed, not just ruby. You might save some hassle by
>> putting that in the readme at the same time as fixing the typo.
>
>> README would definitely help, at least avail if someone cares enough.
>
> I filed an issue for these changes.
>
> https://issues.apache.org/jira/browse/AVRO-427
>
>> However it seems to me that either the "conveniences" are part of the
>> official release or not (this should be made explicit when calling the
>> vote). If not then we should not be considering them as part of the vote.
>
> Technically, what the ASF releases is source code. So, when you vote on
> any release you're voting on its source code, not associated binaries,
> etc. Still, many folks are unaware of this, and Avro's new release
> structure is different than most, so I probably should have mentioned
> that the primary thing to vote on is the src tarball. We also want the
> other artifacts to be correct and useful, of course, but we can, e.g.,
> add more binary artifacts after the release is out, but we should never
> change the released sources.
>
> Apache HTTPD puts docs, binaries, etc. in subtrees:
>
> http://www.apache.org/dist/httpd/
>
> I'd rather we consolidate releases in a single directory. But maybe we
> ought to move each language to a separate subdir, to make this clearer?
> So we'd just have the source tarball in the top-level, and then have
> py, ruby, cpp, c, and java subdirectories. Thoughts?
What you are saying sounds reasonable to me and the changes you've
suggested should go a long way. Having a toplevel avro src archive and
README, with a subdirectory to store the conveniences also sounds good.
Btw, I noticed that the convenience archives have ".svn" subdirectories
in them (I looked at avro-c) containing all the svn info. You might want
to exclude these when doing the pkging.
Patrick
Re: [VOTE] Avro release 1.3.0 (rc 1)
Posted by Doug Cutting <cu...@apache.org>.
Patrick Hunt wrote:
> I tried installing "yajl-ruby" using gem and that failed as "mkmf" was
> not available. It seems that there is also a requirement that "ruby-dev"
> be installed, not just ruby. You might save some hassle by putting that
> in the readme at the same time as fixing the typo.
> README would definitely help, at least avail if someone cares enough.
I filed an issue for these changes.
https://issues.apache.org/jira/browse/AVRO-427
> However it seems to me that either the "conveniences" are part of the
> official release or not (this should be made explicit when calling the
> vote). If not then we should not be considering them as part of the vote.
Technically, what the ASF releases is source code. So, when you vote on
any release you're voting on its source code, not associated binaries,
etc. Still, many folks are unaware of this, and Avro's new release
structure is different than most, so I probably should have mentioned
that the primary thing to vote on is the src tarball. We also want the
other artifacts to be correct and useful, of course, but we can, e.g.,
add more binary artifacts after the release is out, but we should never
change the released sources.
Apache HTTPD puts docs, binaries, etc. in subtrees:
http://www.apache.org/dist/httpd/
I'd rather we consolidate releases in a single directory. But maybe we
ought to move each language to a separate subdir, to make this clearer?
So we'd just have the source tarball in the top-level, and then have
py, ruby, cpp, c, and java subdirectories. Thoughts?
Doug
Re: [VOTE] Avro release 1.3.0 (rc 1)
Posted by Patrick Hunt <ph...@apache.org>.
Doug Cutting wrote:
> Patrick Hunt wrote:
>> I cannot build on Ubuntu Karmic (with all latest apt patches from
>> canonical applied), avro ruby requires echoe which requires a version
>> of gem (not echoe but gem, see below) not avail on Karmic. This seems
>> like it's going to cause problems for a large number of users?
>
> Hmm. I built & tested the release on Ubuntu Karmic. I thought I listed
> all the packages I installed in the README.txt.
>
>> phunt@valhalla:~/a/avro-src-1.3.0$ sudo gem install echoe
>> ERROR: Error installing echoe:
>> gemcutter requires RubyGems version >= 1.3.6
>
> That command works for me. How did you install gem? I used 'sudo
> apt-get install rubygems'.
>
This is weird, I had "rubygems1.8" installed (per apt). I noticed that
there is also "rubygems" pkg available on ubuntu servers. I installed
that and it fixed the problem! That is unusual, esp as "rubygems"
doesn't really have anything in it:
http://packages.ubuntu.com/karmic/all/rubygems/filelist
vs
http://packages.ubuntu.com/karmic/all/rubygems1.8/filelist
regardless, installing that pkg seems to have fixed the problem - I'm
now able to install echoe. (see below, still issues)
>> Also, the README states that the ruby build requires a gem that cannot
>> be found:
>>
>> phunt@valhalla:~/a/avro-src-1.3.0$ sudo gem install jajl-ruby
>> ERROR: could not find gem jajl-ruby locally or in a repository
>
> Oops. That's a typo. Should be 'yajl-ruby'.
I tried installing "yajl-ruby" using gem and that failed as "mkmf" was
not available. It seems that there is also a requirement that "ruby-dev"
be installed, not just ruby. You might save some hassle by putting that
in the readme at the same time as fixing the typo. (btw, usually this is
not an issue, but I just upgraded my machine and I'm starting with a
fresh install of ubuntu karmic 64bit, haven't accreted all the pkgs yet
;-) )
After this point I was able to compile/test all the lang pkgs (although
I didn't try the interop tests) successfully.
>
>> Additionally:
>>
>> What are we voting on, the entire set of files or some subset of files
>> in this release candidate directory? I've always been told Apache
>> requires voting on a single archive containing all of the artifacts
>> that make up the "release". Is this no longer the case?
>
> The primary release artifact is the avro-src-.x.y.x.tar.gz archive. The
> others are generated from this as conveniences. We could, I supposed
> bundle everything up into a single tarball. Do you think that would be
> better? Do you think we should somehow make this clearer, e.g., with a
> README.txt in the distribution?
>
README would definitely help, at least avail if someone cares enough.
However it seems to me that either the "conveniences" are part of the
official release or not (this should be made explicit when calling the
vote). If not then we should not be considering them as part of the vote.
>> FYI test-tools in java fails if JAVA_HOME is not set (but fine for the
>> rest of the build up to that point? why's that? easy to fix?):
>>
>> test-tools:
>> [exec] Error: JAVA_HOME is not set.
>> [exec] + set -o errexit
>> [exec] + '[' '' = '' ']'
>> [exec] + echo 'Error: JAVA_HOME is not set.'
>> [exec] + exit 1
>
> Isn't JAVA_HOME required by lots of tools? For example, the hadoop
> shell scripts all fail if it's not set, no? That said, I don't think we
> use JAVA_HOME for more than finding the java executable, so we could
> instead just run whatever 'java' is on PATH.
>
Most of the time not AFAICT, as I use a number of java tools and I don't
have it set (maybe they set themselves?). First it's come up, granted a
relatively new install of ubuntu. Anyway, as I alluded to, doesn't seem
critical.
>> When I access this release candidate link I see a list of archives,
>> jars, eggs, sha1, md5, pom, etc.... files. Consider adding a README
>> that gives me some insight into what I should download based on my
>> intended usage. I think that would help users significantly.
>
> Yes, that's probably a good idea.
;-)
Regards,
Patrick
Re: [VOTE] Avro release 1.3.0 (rc 1)
Posted by Doug Cutting <cu...@apache.org>.
Patrick Hunt wrote:
> I cannot build on Ubuntu Karmic (with all latest apt patches from
> canonical applied), avro ruby requires echoe which requires a version of
> gem (not echoe but gem, see below) not avail on Karmic. This seems like
> it's going to cause problems for a large number of users?
Hmm. I built & tested the release on Ubuntu Karmic. I thought I listed
all the packages I installed in the README.txt.
> phunt@valhalla:~/a/avro-src-1.3.0$ sudo gem install echoe
> ERROR: Error installing echoe:
> gemcutter requires RubyGems version >= 1.3.6
That command works for me. How did you install gem? I used 'sudo
apt-get install rubygems'.
> Also, the README states that the ruby build requires a gem that cannot
> be found:
>
> phunt@valhalla:~/a/avro-src-1.3.0$ sudo gem install jajl-ruby
> ERROR: could not find gem jajl-ruby locally or in a repository
Oops. That's a typo. Should be 'yajl-ruby'.
> Additionally:
>
> What are we voting on, the entire set of files or some subset of files
> in this release candidate directory? I've always been told Apache
> requires voting on a single archive containing all of the artifacts that
> make up the "release". Is this no longer the case?
The primary release artifact is the avro-src-.x.y.x.tar.gz archive. The
others are generated from this as conveniences. We could, I supposed
bundle everything up into a single tarball. Do you think that would be
better? Do you think we should somehow make this clearer, e.g., with a
README.txt in the distribution?
> FYI test-tools in java fails if JAVA_HOME is not set (but fine for the
> rest of the build up to that point? why's that? easy to fix?):
>
> test-tools:
> [exec] Error: JAVA_HOME is not set.
> [exec] + set -o errexit
> [exec] + '[' '' = '' ']'
> [exec] + echo 'Error: JAVA_HOME is not set.'
> [exec] + exit 1
Isn't JAVA_HOME required by lots of tools? For example, the hadoop
shell scripts all fail if it's not set, no? That said, I don't think we
use JAVA_HOME for more than finding the java executable, so we could
instead just run whatever 'java' is on PATH.
> When I access this release candidate link I see a list of archives,
> jars, eggs, sha1, md5, pom, etc.... files. Consider adding a README that
> gives me some insight into what I should download based on my intended
> usage. I think that would help users significantly.
Yes, that's probably a good idea.
Doug
Re: [VOTE] Avro release 1.3.0 (rc 1)
Posted by Patrick Hunt <ph...@apache.org>.
-1, one blocker and a number of usability issues
I cannot build on Ubuntu Karmic (with all latest apt patches from
canonical applied), avro ruby requires echoe which requires a version of
gem (not echoe but gem, see below) not avail on Karmic. This seems like
it's going to cause problems for a large number of users?
phunt@valhalla:~/a/avro-src-1.3.0$ sudo gem install echoe
ERROR: Error installing echoe:
gemcutter requires RubyGems version >= 1.3.6
phunt@valhalla:~/a/avro-src-1.3.0$ sudo gem update --system
ERROR: While executing gem ... (RuntimeError)
gem update --system is disabled on Debian. RubyGems can be updated
using the official Debian repositories by aptitude or apt-get.
Also, the README states that the ruby build requires a gem that cannot
be found:
phunt@valhalla:~/a/avro-src-1.3.0$ sudo gem install jajl-ruby
ERROR: could not find gem jajl-ruby locally or in a repository
Additionally:
What are we voting on, the entire set of files or some subset of files
in this release candidate directory? I've always been told Apache
requires voting on a single archive containing all of the artifacts that
make up the "release". Is this no longer the case?
FYI test-tools in java fails if JAVA_HOME is not set (but fine for the
rest of the build up to that point? why's that? easy to fix?):
test-tools:
[exec] Error: JAVA_HOME is not set.
[exec] + set -o errexit
[exec] + '[' '' = '' ']'
[exec] + echo 'Error: JAVA_HOME is not set.'
[exec] + exit 1
When I access this release candidate link I see a list of archives,
jars, eggs, sha1, md5, pom, etc.... files. Consider adding a README that
gives me some insight into what I should download based on my intended
usage. I think that would help users significantly.
Patrick
Doug Cutting wrote:
> I have created a second candidate build for Avro release 1.3.0.
>
> Please download, test, and vote by 24 February.
>
> http://people.apache.org/~cutting/avro-1.3.0-rc1/
>
> Thanks,
>
> Doug
Re: [VOTE] Avro release 1.3.0 (rc 1)
Posted by Scott Carey <sc...@richrelevance.com>.
There is a minor bug in the spec document.
https://issues.apache.org/jira/browse/AVRO-424
I've attached the patch for it in the ticket.
On Feb 19, 2010, at 4:15 PM, Doug Cutting wrote:
> I have created a second candidate build for Avro release 1.3.0.
>
> Please download, test, and vote by 24 February.
>
> http://people.apache.org/~cutting/avro-1.3.0-rc1/
>
> Thanks,
>
> Doug
Re: [VOTE] Avro release 1.3.0 (rc 1)
Posted by Doug Cutting <cu...@apache.org>.
Ryan King wrote:
> Would it be too late to get rubygems building in for 1.3?
We just need a patch that causes the top-level './build.sh dist' to
create this in the top-level dist/ directory.
I don't think the lack of this should block 1.3.0, but this might be a
great thing to include in a 1.3.1 release. We could even, by hand,
after the fact, post a ruby gem for the 1.3.0 ruby sources with the
1.3.0 release, but I'd rather just roll this kind of thing out in a
1.3.1 release, along with other compatible fixes.
Doug
Re: [VOTE] Avro release 1.3.0 (rc 1)
Posted by Ryan King <ry...@twitter.com>.
Would it be too late to get rubygems building in for 1.3?
-ryan
On Fri, Feb 19, 2010 at 5:22 PM, Jeff Hammerbacher <ha...@cloudera.com> wrote:
> I note that the Python egg has "python2.6" in the name; given that Python
> 2.4 is the default for CentOS, that's the version we've targeted as a
> minimum. Perhaps rebuild with a lower version of Python?
>
> On Fri, Feb 19, 2010 at 5:18 PM, Matt Massie <ma...@cloudera.com> wrote:
>
>> I'm +1 for rc1.
>>
>> * avro-doc bug is fixed and C documentation is correct
>> * avro-c builds on MacOS/Linux with all unit tests passing
>> * md5 signature matches for avro-c tarball
>>
>> -Matt
>>
>> On Fri, Feb 19, 2010 at 4:15 PM, Doug Cutting <cu...@apache.org> wrote:
>>
>> > I have created a second candidate build for Avro release 1.3.0.
>> >
>> > Please download, test, and vote by 24 February.
>> >
>> > http://people.apache.org/~cutting/avro-1.3.0-rc1/<http://people.apache.org/%7Ecutting/avro-1.3.0-rc1/>
>> >
>> > Thanks,
>> >
>> > Doug
>> >
>>
>
Re: [VOTE] Avro release 1.3.0 (rc 1)
Posted by Jeff Hammerbacher <ha...@cloudera.com>.
I note that the Python egg has "python2.6" in the name; given that Python
2.4 is the default for CentOS, that's the version we've targeted as a
minimum. Perhaps rebuild with a lower version of Python?
On Fri, Feb 19, 2010 at 5:18 PM, Matt Massie <ma...@cloudera.com> wrote:
> I'm +1 for rc1.
>
> * avro-doc bug is fixed and C documentation is correct
> * avro-c builds on MacOS/Linux with all unit tests passing
> * md5 signature matches for avro-c tarball
>
> -Matt
>
> On Fri, Feb 19, 2010 at 4:15 PM, Doug Cutting <cu...@apache.org> wrote:
>
> > I have created a second candidate build for Avro release 1.3.0.
> >
> > Please download, test, and vote by 24 February.
> >
> > http://people.apache.org/~cutting/avro-1.3.0-rc1/<http://people.apache.org/%7Ecutting/avro-1.3.0-rc1/>
> >
> > Thanks,
> >
> > Doug
> >
>
Re: [VOTE] Avro release 1.3.0 (rc 1)
Posted by Matt Massie <ma...@cloudera.com>.
I'm +1 for rc1.
* avro-doc bug is fixed and C documentation is correct
* avro-c builds on MacOS/Linux with all unit tests passing
* md5 signature matches for avro-c tarball
-Matt
On Fri, Feb 19, 2010 at 4:15 PM, Doug Cutting <cu...@apache.org> wrote:
> I have created a second candidate build for Avro release 1.3.0.
>
> Please download, test, and vote by 24 February.
>
> http://people.apache.org/~cutting/avro-1.3.0-rc1/
>
> Thanks,
>
> Doug
>