Hey,

I just pushed a fix to a not so nice bug in the Python client, where I was
not handling the CLIENT HandshakeMatch value correctly (rather than
processing the response, I was sending another RPC). For anyone using a
Python client, they're sending two RPCs any time the server has seen them
before but they have not seen the server before--pretty ugly, particularly
for non-idempotent server-side operations. I would love to get a release out
ASAP so folks can avoid this error. Worth it?

Thanks,
Jeff

Got lots of goodies on the ruby side, too. Need a day to double check I'm
not doing this same thing but would be good to go after that.
--
Jeff

On May 24, 2010 3:22 AM, "Jeff Hammerbacher" <[EMAIL PROTECTED]> wrote:

Hey,

I just pushed a fix to a not so nice bug in the Python client, where I was
not handling the CLIENT HandshakeMatch value correctly (rather than
processing the response, I was sending another RPC). For anyone using a
Python client, they're sending two RPCs any time the server has seen them
before but they have not seen the server before--pretty ugly, particularly
for non-idempotent server-side operations. I would love to get a release out
ASAP so folks can avoid this error. Worth it?

Thanks,
Jeff

To be clear, this would need to be a branch from 1.3.2 ... the stuff on HEAD
for Avro C is 1.4 material (in-progress breaking API changes).

 - Bruce

On Mon, May 24, 2010 at 6:04 PM, Jeff Hodges <[EMAIL PROTECTED]> wrote:

> Got lots of goodies on the ruby side, too. Need a day to double check I'm
> not doing this same thing but would be good to go after that.
> --
> Jeff
>
> On May 24, 2010 3:22 AM, "Jeff Hammerbacher" <[EMAIL PROTECTED]> wrote:
>
> Hey,
>
> I just pushed a fix to a not so nice bug in the Python client, where I was
> not handling the CLIENT HandshakeMatch value correctly (rather than
> processing the response, I was sending another RPC). For anyone using a
> Python client, they're sending two RPCs any time the server has seen them
> before but they have not seen the server before--pretty ugly, particularly
> for non-idempotent server-side operations. I would love to get a release
> out
> ASAP so folks can avoid this error. Worth it?
>
> Thanks,
> Jeff
>

On 05/24/2010 05:20 AM, Bruce Mitchener wrote:
> To be clear, this would need to be a branch from 1.3.2 ... the stuff on HEAD
> for Avro C is 1.4 material (in-progress breaking API changes).

There's already a 1.3 branch in subversion.  All bugfixes should
generally be first committed to trunk.  The process should be roughly:

- add a 1.3.3 target in Jira
- add to CHANGES.txt a 1.3.3 section in both trunk/ and branch-1.3/
- merge selected bugfixes from trunk/ to branch-1.3/
   - as the merge is committed, set "fix-for" to be 1.3.3 in jira
   - update CHANGES.txt in both trunk/ and branch-1.3/

Once we're happy with the set of bugfixes in 1.3.3 then someone can tag
it with a candidate tag, roll a release candidate, and call a vote.

Does that sound reasonble?

Doug

Yep, sounds reasonable. I took care of:

- add a 1.3.3 target in Jira
- add to CHANGES.txt a 1.3.3 section in both trunk/ and branch-1.3/

For the various languages, could others take care of:

- add a 1.3.3 target in Jira
- add to CHANGES.txt a 1.3.3 section in both trunk/ and branch-1.3/
- merge selected bugfixes from trunk/ to branch-1.3/
 - as the merge is committed, set "fix-for" to be 1.3.3 in jira
 - update CHANGES.txt in both trunk/ and branch-1.3/

Once you've taken care of the above for your language, make note of it on
this thread. Once I've heard from everyone, we'll proceed with a release
candidate.

Thanks,
Jeff

On Mon, May 24, 2010 at 11:16 AM, Doug Cutting <[EMAIL PROTECTED]> wrote:

> On 05/24/2010 05:20 AM, Bruce Mitchener wrote:
>
>> To be clear, this would need to be a branch from 1.3.2 ... the stuff on
>> HEAD
>> for Avro C is 1.4 material (in-progress breaking API changes).
>>
>
> There's already a 1.3 branch in subversion.  All bugfixes should generally
> be first committed to trunk.  The process should be roughly:
>
> - add a 1.3.3 target in Jira
> - add to CHANGES.txt a 1.3.3 section in both trunk/ and branch-1.3/
> - merge selected bugfixes from trunk/ to branch-1.3/
>  - as the merge is committed, set "fix-for" to be 1.3.3 in jira
>  - update CHANGES.txt in both trunk/ and branch-1.3/
>
> Once we're happy with the set of bugfixes in 1.3.3 then someone can tag it
> with a candidate tag, roll a release candidate, and call a vote.
>
> Does that sound reasonble?
>
> Doug
>

Gah; for the other languages section, the only things to take care of are:

- merge selected bugfixes from trunk/ to branch-1.3/
 - as the merge is committed, set "fix-for" to be 1.3.3 in jira
 - update CHANGES.txt in both trunk/ and branch-1.3/
On Mon, May 24, 2010 at 1:32 PM, Jeff Hammerbacher <[EMAIL PROTECTED]>wrote:

> Yep, sounds reasonable. I took care of:
>
>
> - add a 1.3.3 target in Jira
> - add to CHANGES.txt a 1.3.3 section in both trunk/ and branch-1.3/
>
> For the various languages, could others take care of:
>
>
> - add a 1.3.3 target in Jira
> - add to CHANGES.txt a 1.3.3 section in both trunk/ and branch-1.3/
> - merge selected bugfixes from trunk/ to branch-1.3/
>  - as the merge is committed, set "fix-for" to be 1.3.3 in jira
>  - update CHANGES.txt in both trunk/ and branch-1.3/
>
> Once you've taken care of the above for your language, make note of it on
> this thread. Once I've heard from everyone, we'll proceed with a release
> candidate.
>
> Thanks,
> Jeff
>
>
> On Mon, May 24, 2010 at 11:16 AM, Doug Cutting <[EMAIL PROTECTED]> wrote:
>
>> On 05/24/2010 05:20 AM, Bruce Mitchener wrote:
>>
>>> To be clear, this would need to be a branch from 1.3.2 ... the stuff on
>>> HEAD
>>> for Avro C is 1.4 material (in-progress breaking API changes).
>>>
>>
>> There's already a 1.3 branch in subversion.  All bugfixes should generally
>> be first committed to trunk.  The process should be roughly:
>>
>> - add a 1.3.3 target in Jira
>> - add to CHANGES.txt a 1.3.3 section in both trunk/ and branch-1.3/
>> - merge selected bugfixes from trunk/ to branch-1.3/
>>  - as the merge is committed, set "fix-for" to be 1.3.3 in jira
>>  - update CHANGES.txt in both trunk/ and branch-1.3/
>>
>> Once we're happy with the set of bugfixes in 1.3.3 then someone can tag it
>> with a candidate tag, roll a release candidate, and call a vote.
>>
>> Does that sound reasonble?
>>
>> Doug
>>
>
>

Hey,

I've merged in the Python patches for 1.3.3. I'm going to cut a 1.3.3
release candidate on this Friday morning, June 4. Please merge any bug fixes
in by then.

Regards,
Jeff

On Mon, May 24, 2010 at 1:33 PM, Jeff Hammerbacher <[EMAIL PROTECTED]>wrote:

> Gah; for the other languages section, the only things to take care of are:
>
>
> - merge selected bugfixes from trunk/ to branch-1.3/
>  - as the merge is committed, set "fix-for" to be 1.3.3 in jira
>  - update CHANGES.txt in both trunk/ and branch-1.3/
>
>
> On Mon, May 24, 2010 at 1:32 PM, Jeff Hammerbacher <[EMAIL PROTECTED]>wrote:
>
>> Yep, sounds reasonable. I took care of:
>>
>>
>> - add a 1.3.3 target in Jira
>> - add to CHANGES.txt a 1.3.3 section in both trunk/ and branch-1.3/
>>
>> For the various languages, could others take care of:
>>
>>
>> - add a 1.3.3 target in Jira
>> - add to CHANGES.txt a 1.3.3 section in both trunk/ and branch-1.3/
>> - merge selected bugfixes from trunk/ to branch-1.3/
>>  - as the merge is committed, set "fix-for" to be 1.3.3 in jira
>>  - update CHANGES.txt in both trunk/ and branch-1.3/
>>
>> Once you've taken care of the above for your language, make note of it on
>> this thread. Once I've heard from everyone, we'll proceed with a release
>> candidate.
>>
>> Thanks,
>> Jeff
>>
>>
>> On Mon, May 24, 2010 at 11:16 AM, Doug Cutting <[EMAIL PROTECTED]>wrote:
>>
>>> On 05/24/2010 05:20 AM, Bruce Mitchener wrote:
>>>
>>>> To be clear, this would need to be a branch from 1.3.2 ... the stuff on
>>>> HEAD
>>>> for Avro C is 1.4 material (in-progress breaking API changes).
>>>>
>>>
>>> There's already a 1.3 branch in subversion.  All bugfixes should
>>> generally be first committed to trunk.  The process should be roughly:
>>>
>>> - add a 1.3.3 target in Jira
>>> - add to CHANGES.txt a 1.3.3 section in both trunk/ and branch-1.3/
>>> - merge selected bugfixes from trunk/ to branch-1.3/
>>>  - as the merge is committed, set "fix-for" to be 1.3.3 in jira
>>>  - update CHANGES.txt in both trunk/ and branch-1.3/
>>>
>>> Once we're happy with the set of bugfixes in 1.3.3 then someone can tag
>>> it with a candidate tag, roll a release candidate, and call a vote.
>>>
>>> Does that sound reasonble?
>>>
>>> Doug
>>>
>>
>>
>

On 06/01/2010 10:05 AM, Jeff Hammerbacher wrote:
> I've merged in the Python patches for 1.3.3. I'm going to cut a 1.3.3
> release candidate on this Friday morning, June 4. Please merge any bug fixes
> in by then.

I suspect most of the following should be merged to 1.3:

C:

AVRO-502 Memory leak from parsing JSON schema.

C++

AVRO-518 make check in c++ is broken because of typo
AVRO-515 Fix build and compatibility problems

Java:

AVRO-524 DataFileWriter.appendTo leads to intermittent IOException
AVRO-517 Resolving Decoder fails in some cases
AVRO-499 reflection does not handle interfaces with overloaded methods

Ruby:

AVRO-554 data files created by ruby DataWriter are extremely large
AVRO-500 ruby side dev packaging
AVRO-489 ruby implementation should skip complex objects
AVRO-461 ruby side cannot skip primitives
AVRO-555 missing license header
AVRO-450 Python - Ruby interoperability failing
AVRO-516 ruby: buffer length should not be little-endian in socket rpc

I'm happy to merge these Java issues to the 1.3 branch.  Do we have
volunteers for the others?

Remember, in addition to merging the code changes, the CHANGES.txt in
both the branch and trunk need to be updated, and the "fix version" for
each issue needs to be updated in Jira.

Doug

I'm going to merge those over for the ruby side.
--
Jeff

On Tue, Jun 1, 2010 at 10:59 AM, Doug Cutting <[EMAIL PROTECTED]> wrote:
> On 06/01/2010 10:05 AM, Jeff Hammerbacher wrote:
>>
>> I've merged in the Python patches for 1.3.3. I'm going to cut a 1.3.3
>> release candidate on this Friday morning, June 4. Please merge any bug
>> fixes
>> in by then.
>
> I suspect most of the following should be merged to 1.3:
>
> C:
>
> AVRO-502 Memory leak from parsing JSON schema.
>
> C++
>
> AVRO-518 make check in c++ is broken because of typo
> AVRO-515 Fix build and compatibility problems
>
> Java:
>
> AVRO-524 DataFileWriter.appendTo leads to intermittent IOException
> AVRO-517 Resolving Decoder fails in some cases
> AVRO-499 reflection does not handle interfaces with overloaded methods
>
> Ruby:
>
> AVRO-554 data files created by ruby DataWriter are extremely large
> AVRO-500 ruby side dev packaging
> AVRO-489 ruby implementation should skip complex objects
> AVRO-461 ruby side cannot skip primitives
> AVRO-555 missing license header
> AVRO-450 Python - Ruby interoperability failing
> AVRO-516 ruby: buffer length should not be little-endian in socket rpc
>
> I'm happy to merge these Java issues to the 1.3 branch.  Do we have
> volunteers for the others?
>
> Remember, in addition to merging the code changes, the CHANGES.txt in both
> the branch and trunk need to be updated, and the "fix version" for each
> issue needs to be updated in Jira.
>
> Doug
>

On 06/01/2010 10:59 AM, Doug Cutting wrote:
> Java:
>
> AVRO-524 DataFileWriter.appendTo leads to intermittent IOException
> AVRO-517 Resolving Decoder fails in some cases
> AVRO-499 reflection does not handle interfaces with overloaded methods

I have merged all of these to the 1.3 branch, so Java's now good to go
for 1.3.3.

Doug