I have created a third candidate build for Avro release 1.3.0.

Please download, test, and vote by 26 February.

http://people.apache.org/~cutting/avro-1.3.0-rc2/

Thanks,

Doug

+1 for this release candidate:

* avro-doc has correct C documentation
* md5 signature file is correct for avro-c
* avro-c 'make distcheck' succeeds on MacOS X and Linux
* no '.svn' directories in the avro-c tarball anymore

-Matt

On Tue, Feb 23, 2010 at 3:53 PM, Doug Cutting <[EMAIL PROTECTED]> wrote:

> I have created a third candidate build for Avro release 1.3.0.
>
> Please download, test, and vote by 26 February.
>
> http://people.apache.org/~cutting/avro-1.3.0-rc2/
>
> Thanks,
>
> Doug
>

+1, looks sharp! I did a 'build.sh test' in the toplevel of src pkg. md5
for that file looks good as well.
Btw, "build.sh test" finished with this:

...
RPC INTEROP TESTS PASS
share/test/interop/bin/test_rpc_interop.sh: line 43: kill: (4981) - No
such process

this means everything is OK right? It might be good in the next version
to have the build.sh clearly detail whether the tests were successful or
not.
Patrick

Doug Cutting wrote:
> I have created a third candidate build for Avro release 1.3.0.
>
> Please download, test, and vote by 26 February.
>
> http://people.apache.org/~cutting/avro-1.3.0-rc2/
>
> Thanks,
>
> Doug

+1, Looks good to me.  
Deployed java artifacts to a maven repository and integrated into build system successfully.  All application tests using Avro pass.  Maven source and javadoc artifacts are automatically detected by Eclipse + M2Eclipse.

Spec looks fine other than the minor detail mentioned previously.  Quick doc scan looks ok.

-Scott

On Feb 23, 2010, at 4:58 PM, Patrick Hunt wrote:

> +1, looks sharp! I did a 'build.sh test' in the toplevel of src pkg. md5
> for that file looks good as well.
>
>
> Btw, "build.sh test" finished with this:
>
> ...
> RPC INTEROP TESTS PASS
> share/test/interop/bin/test_rpc_interop.sh: line 43: kill: (4981) - No
> such process
>
> this means everything is OK right? It might be good in the next version
> to have the build.sh clearly detail whether the tests were successful or
> not.
>
>
> Patrick
>
> Doug Cutting wrote:
>> I have created a third candidate build for Avro release 1.3.0.
>>
>> Please download, test, and vote by 26 February.
>>
>> http://people.apache.org/~cutting/avro-1.3.0-rc2/
>>
>> Thanks,
>>
>> Doug

+1
"build.sh dist" looks fine to me.

"build.sh test" seems to fail for interop tests, but I suspect it's my
environment and haven't had a chance to investigate why.  I assume others
would have flagged this otherwise.

I also notice that the interop tests run the whole configure/build chain for
C again (instead of re-using the build that was created from the previous
unit tests).  Is that intentional?
Scott
On 2/23/10 3:53 PM, "Doug Cutting" said:

> I have created a third candidate build for Avro release 1.3.0.
>
> Please download, test, and vote by 26 February.
>
> http://people.apache.org/~cutting/avro-1.3.0-rc2/
>
> Thanks,
>
> Doug

Scott Banachowski wrote:
> "build.sh test" seems to fail for interop tests, but I suspect it's my
> environment and haven't had a chance to investigate why.  I assume others
> would have flagged this otherwise.

What environment?  How did they fail?

> I also notice that the interop tests run the whole configure/build chain for
> C again (instead of re-using the build that was created from the previous
> unit tests).  Is that intentional?

That should probably be avoided.

The 'dist' target also seems to run some tests, when it doesn't need to.
  So the build could certainly be streamlined.

Doug

On Wed, Feb 24, 2010 at 10:39 AM, Doug Cutting <[EMAIL PROTECTED]> wrote:

> Scott Banachowski wrote:
>
>> "build.sh test" seems to fail for interop tests, but I suspect it's my
>> environment and haven't had a chance to investigate why.  I assume others
>> would have flagged this otherwise.
>>
>
> What environment?  How did they fail?
>
>
>  I also notice that the interop tests run the whole configure/build chain
>> for
>> C again (instead of re-using the build that was created from the previous
>> unit tests).  Is that intentional?
>>
>
> That should probably be avoided.
>

I can optimize this in future releases.  I opted for the simpler/paranoid
approach.  It important to make the interop tests fast and easy to use since
we'll use them often in development and interop is critical.  Sorry for a
current overhead.

> The 'dist' target also seems to run some tests, when it doesn't need to.
>  So the build could certainly be streamlined.
>

Part of creating a distributable artifact that is guaranteed to work with a
simple './configure;make' is building the code and running all the unit
tests inside the newly generated package.  This cost is paid up front when
we generate the artifact so I don't see it as a problem.  Consumers of Avro
C will benefit from it immensely.

-Matt

Matt Massie wrote:
> Part of creating a distributable artifact that is guaranteed to work with a
> simple './configure;make' is building the code and running all the unit
> tests inside the newly generated package.

That was not my intent for the 'dist' target.  The 'dist' target is
meant to only generate artifacts for distribution.  One should run tests
before one distributes, but the 'dist' target should not itself run
those tests.

Doug

On Wed, Feb 24, 2010 at 10:56 AM, Doug Cutting <[EMAIL PROTECTED]> wrote:

> Matt Massie wrote:
>
>> Part of creating a distributable artifact that is guaranteed to work with
>> a
>> simple './configure;make' is building the code and running all the unit
>> tests inside the newly generated package.
>>
>
> That was not my intent for the 'dist' target.  The 'dist' target is meant
> to only generate artifacts for distribution.  One should run tests before
> one distributes, but the 'dist' target should not itself run those tests.
Running the tests inside the build directory and running the tests inside
the newly generated package/tarball are two different things.  It's possible
for unit tests to pass in the source directory and fail when generating the
distributable tarball (e.g. failed to include a source file in the
manifest).  The tests are not just testing source.  They are testing
building the source in a particular build environment/ directory structure.

Currently running 'make clean distcheck' takes 47 secs on my Macbook.
 That's a small price to pay for piece of mind in my opinion.

-Matt

On 2/24/10 10:39 AM, "Doug Cutting" said:

> Scott Banachowski wrote:
>> "build.sh test" seems to fail for interop tests, but I suspect it's my
>> environment and haven't had a chance to investigate why.  I assume others
>> would have flagged this otherwise.
>
> What environment?  How did they fail?
>

Here's the output of the tail end of the build, where it fails for me:
creating test_interop_data
Making all in examples
/Users/sbanacho/candidate/avro-src-1.3.0/build/c/examples
make[2]: Nothing to be done for `all'.
make[2]: Nothing to be done for `all-am'.
+ cd lang/ruby
/Users/sbanacho/candidate/avro-src-1.3.0/lang/ruby
+ rake interop
(in /Users/sbanacho/candidate/avro-src-1.3.0/lang/ruby)
rake aborted!
no such file to load -- echoe
/Users/sbanacho/candidate/avro-src-1.3.0/lang/ruby/rakefile:18
(See full trace by running task with --trace)
+ /bin/bash share/test/interop/bin/test_rpc_interop.sh
/Users/sbanacho/candidate/avro-src-1.3.0
TEST: share/test/interop/rpc/add/onePlusOne
177 [main] INFO org.mortbay.log - Logging to
org.slf4j.impl.SimpleLogger(org.mortbay.log) via org.mortbay.log.Slf4jLog
203 [main] INFO org.mortbay.log - jetty-1.3.0
267 [main] INFO org.mortbay.log - Started SocketConnector@0.0.0.0:51300
2
Closing server.
175 [main] INFO org.mortbay.log - Logging to
org.slf4j.impl.SimpleLogger(org.mortbay.log) via org.mortbay.log.Slf4jLog
201 [main] INFO org.mortbay.log - jetty-1.3.0
258 [main] INFO org.mortbay.log - Started SocketConnector@0.0.0.0:51306
Traceback (most recent call last):
  File "lang/py/src/avro/tool.py", line 26, in <module>
    from avro import io
  File "/Users/sbanacho/candidate/avro-src-1.3.0/lang/py/src/avro/io.py",
line 40, in <module>
    from avro import schema
  File
"/Users/sbanacho/candidate/avro-src-1.3.0/lang/py/src/avro/schema.py", line
39, in <module>
    import json
ImportError: No module named json

Scott-

It looks like you need to install the simplejson python module on your box.

-Matt

On Wed, Feb 24, 2010 at 11:01 AM, Scott Banachowski
<[EMAIL PROTECTED]>wrote:

>
>
>
> On 2/24/10 10:39 AM, "Doug Cutting" said:
>
> > Scott Banachowski wrote:
> >> "build.sh test" seems to fail for interop tests, but I suspect it's my
> >> environment and haven't had a chance to investigate why.  I assume
> others
> >> would have flagged this otherwise.
> >
> > What environment?  How did they fail?
> >
>
> Here's the output of the tail end of the build, where it fails for me:
>
>
> creating test_interop_data
> Making all in examples
> /Users/sbanacho/candidate/avro-src-1.3.0/build/c/examples
> make[2]: Nothing to be done for `all'.
> make[2]: Nothing to be done for `all-am'.
> + cd lang/ruby
> /Users/sbanacho/candidate/avro-src-1.3.0/lang/ruby
> + rake interop
> (in /Users/sbanacho/candidate/avro-src-1.3.0/lang/ruby)
> rake aborted!
> no such file to load -- echoe
> /Users/sbanacho/candidate/avro-src-1.3.0/lang/ruby/rakefile:18
> (See full trace by running task with --trace)
> + /bin/bash share/test/interop/bin/test_rpc_interop.sh
> /Users/sbanacho/candidate/avro-src-1.3.0
> TEST: share/test/interop/rpc/add/onePlusOne
> 177 [main] INFO org.mortbay.log - Logging to
> org.slf4j.impl.SimpleLogger(org.mortbay.log) via org.mortbay.log.Slf4jLog
> 203 [main] INFO org.mortbay.log - jetty-1.3.0
> 267 [main] INFO org.mortbay.log - Started SocketConnector@0.0.0.0:51300
> 2
> Closing server.
> 175 [main] INFO org.mortbay.log - Logging to
> org.slf4j.impl.SimpleLogger(org.mortbay.log) via org.mortbay.log.Slf4jLog
> 201 [main] INFO org.mortbay.log - jetty-1.3.0
> 258 [main] INFO org.mortbay.log - Started SocketConnector@0.0.0.0:51306
> Traceback (most recent call last):
>  File "lang/py/src/avro/tool.py", line 26, in <module>
>    from avro import io
>  File "/Users/sbanacho/candidate/avro-src-1.3.0/lang/py/src/avro/io.py",
> line 40, in <module>
>    from avro import schema
>  File
> "/Users/sbanacho/candidate/avro-src-1.3.0/lang/py/src/avro/schema.py", line
> 39, in <module>
>    import json
> ImportError: No module named json
>
>

Thanks Matt.  It seems to work now.  I figured I was missing something.

BTW, the tests seem anti-climatic after they're all over.  It'd be nice if
the build.sh script printed out a big "Success!"  message at the end if
everything passed.  Maybe for 1.4?

Scott
On 2/24/10 11:07 AM, "Matt Massie" said:

> Scott-
>
> It looks like you need to install the simplejson python module on your box.
>
> -Matt
>
> On Wed, Feb 24, 2010 at 11:01 AM, Scott Banachowski
> <[EMAIL PROTECTED]>wrote:
>
>>
>>
>>
>> On 2/24/10 10:39 AM, "Doug Cutting" said:
>>
>>> Scott Banachowski wrote:
>>>> "build.sh test" seems to fail for interop tests, but I suspect it's my
>>>> environment and haven't had a chance to investigate why.  I assume
>> others
>>>> would have flagged this otherwise.
>>>
>>> What environment?  How did they fail?
>>>
>>
>> Here's the output of the tail end of the build, where it fails for me:
>>
>>
>> creating test_interop_data
>> Making all in examples
>> /Users/sbanacho/candidate/avro-src-1.3.0/build/c/examples
>> make[2]: Nothing to be done for `all'.
>> make[2]: Nothing to be done for `all-am'.
>> + cd lang/ruby
>> /Users/sbanacho/candidate/avro-src-1.3.0/lang/ruby
>> + rake interop
>> (in /Users/sbanacho/candidate/avro-src-1.3.0/lang/ruby)
>> rake aborted!
>> no such file to load -- echoe
>> /Users/sbanacho/candidate/avro-src-1.3.0/lang/ruby/rakefile:18
>> (See full trace by running task with --trace)
>> + /bin/bash share/test/interop/bin/test_rpc_interop.sh
>> /Users/sbanacho/candidate/avro-src-1.3.0
>> TEST: share/test/interop/rpc/add/onePlusOne
>> 177 [main] INFO org.mortbay.log - Logging to
>> org.slf4j.impl.SimpleLogger(org.mortbay.log) via org.mortbay.log.Slf4jLog
>> 203 [main] INFO org.mortbay.log - jetty-1.3.0
>> 267 [main] INFO org.mortbay.log - Started SocketConnector@0.0.0.0:51300
>> 2
>> Closing server.
>> 175 [main] INFO org.mortbay.log - Logging to
>> org.slf4j.impl.SimpleLogger(org.mortbay.log) via org.mortbay.log.Slf4jLog
>> 201 [main] INFO org.mortbay.log - jetty-1.3.0
>> 258 [main] INFO org.mortbay.log - Started SocketConnector@0.0.0.0:51306
>> Traceback (most recent call last):
>>  File "lang/py/src/avro/tool.py", line 26, in <module>
>>    from avro import io
>>  File "/Users/sbanacho/candidate/avro-src-1.3.0/lang/py/src/avro/io.py",
>> line 40, in <module>
>>    from avro import schema
>>  File
>> "/Users/sbanacho/candidate/avro-src-1.3.0/lang/py/src/avro/schema.py", line
>> 39, in <module>
>>    import json
>> ImportError: No module named json
>>
>>

+1

I successfully tested with Cygwin for Java, C++. I couldn't build py and c
(and tools part of Java), but we can address them post 1.3.

Thanks

Thiru

-----Original Message-----
From: Doug Cutting [mailto:[EMAIL PROTECTED]]
Sent: Wednesday, February 24, 2010 5:24 AM
To: [EMAIL PROTECTED]
Subject: [VOTE] Avro release 1.3.0 (rc 2)

I have created a third candidate build for Avro release 1.3.0.

Please download, test, and vote by 26 February.

http://people.apache.org/~cutting/avro-1.3.0-rc2/

Thanks,

Doug

+1

I checked the signature and checksums for the source package, and ran
the tests on Mac OS 10.5.8.

Cheers,
Tom

On Tue, Feb 23, 2010 at 3:53 PM, Doug Cutting <[EMAIL PROTECTED]> wrote:
> I have created a third candidate build for Avro release 1.3.0.
>
> Please download, test, and vote by 26 February.
>
> http://people.apache.org/~cutting/avro-1.3.0-rc2/
>
> Thanks,
>
> Doug
>

+1 from me.

With three +1 votes from PMC members, and no -1 votes, this passes.

I'll publish this release and announce it Monday.

Thanks!

Doug

Doug Cutting wrote:
> I have created a third candidate build for Avro release 1.3.0.
>
> Please download, test, and vote by 26 February.
>
> http://people.apache.org/~cutting/avro-1.3.0-rc2/
>
> Thanks,
>
> Doug