You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@avro.apache.org by Niels Basjes <Ni...@basjes.nl> on 2017/05/17 08:55:11 UTC
Why are there so many fixes missing in the 1.8.2 release ?!?
Hi,
Just now I ran into an obscure problem in the 1.8.2 release I thought I had
already fixed.
Researching the issue I found that some of the fixes that have been
committed to the master over the last few months have not been included in
this release.
I myself made some of those fixes and I would really like to know: What
went wrong? What did I do wrong?
To get some insight I simply did a diff of the CHANGELOG and found these to
be missing:
AVRO-1993: C++ Byte ordering macro does not work on FreeBSD (thiru)
AVRO-1975: Upgrade java dependencies (gabor)
AVRO-1960: Add log4j properties for avro-tools
AVRO-1748. Add Snappy Compression to C++ DataFile (J. Langley via thiru)
AVRO-1626: C#: Fix Avro.pref build error. (Naruto Takahashi via blue)
AVRO-1966: Java: Fix NPE When copying builder with nullable record.
(Niels Basjes)
AVRO-1967: Java: Fix NPE when calling getXyzBuilder on instance where
the xyz is null (Niels Basjes)
AVRO-1970: Java: Flaky test: TestInputBytes. (Gabor Szadovszky via tomwhite)
AVRO-1881: Java: Avro (Java) Memory Leak when reusing JsonDecoder
instance. (Nandor Kollar via tomwhite)
AVRO-1954: Java: Schema.Field.defaultVal() generates: Unknown datum
type (Nandor Kollar via tomwhite)
AVRO-1930: JsonParser doesn't handle integer scientific notation
(Pietro Cerutti via thiru)
AVRO-1912: C++ Resolving Decoding doesn't work if element removed from
record in array. (via thiru)
AVRO-1866. JsonNullFormatter fwd-declared as class, defined as struct
( Pietro Cerutti via thiru)
AVRO-1750. GenericDatum API behavior breaking change (thiru)
AVRO-1995: JSON Parser does not properly check current state (Victor
Mota via thiru)
AVRO-1216. Setting precision for the output stream (John McClean via thiru)
AVRO-1937: C++ generator for recursive structure crashes (thiru)
AVRO-1892. C++ library cannot parse unions with default values (Hua
Zhang via thiru)
AVRO-1994. C++ Code Generator Generates Invalid Code if Field is of
type Null (Darryl Green via thiru)
AVRO-1997. Avro Field.defaultVal broken for Fixed fields. (Zoltan
Farkasi via thiru)
AVRO-1838: Java: Update checkstyle to catch trailing whitespace.
(nielsbasjes via blue)
Since several of these are NPE/crashes area I think we should consider
getting 1.8.3 out quicker than what we would normally do.
--
Best regards / Met vriendelijke groeten,
Niels Basjes
Re: Why are there so many fixes missing in the 1.8.2 release ?!?
Posted by Sean Busbey <bu...@cloudera.com>.
Given our recent history of releases, I suspect we should revisit this
approach. The fewer steps a release manager has to do (esp those
things we can spread across committers) the more likely we are to
continue to find volunteers who'll get things out at a regular
cadence.
On Thu, May 18, 2017 at 2:47 PM, Ryan Blue <rb...@netflix.com.invalid> wrote:
> I didn't think that the only way to get something into a release was to
> backport it immediately. When I was RM, I would look through the new
> commits on master and backport what I thought was safe. That step is in the
> release documentation (step 7
> <https://cwiki.apache.org/confluence/display/AVRO/How+To+Release>).
>
> In this case, the 1.8.2 release was delayed after the first few votes
> failed, so I think it was a reasonable call to get the release out... but
> it would be nice to get a 1.8.3 out as well to pick up the new fixes.
>
> rb
>
> On Thu, May 18, 2017 at 2:12 PM, Sean Busbey <bu...@cloudera.com> wrote:
>
>> (Repeating my comments from the comment on the 1.8.2 release jira):
>>
>> Master is targetting 1.9.0 now, if the committer of the fix doesn't
>> cherry pick back to branch 1.8 or branch 1.7 before closing then those
>> things won't get into new 1.8 or 1.7 releases.
>>
>> branch-1.8 broke off of master in December 2015, so for example
>> AVRO-1966 looks like it was committed only to master but the fix
>> version was set to 1.8.2 instead of 1.9.0.
>>
>> I have some release process notes I use in Apache HBase to check how
>> well JIRA and git mesh up with each other, we could try making use of
>> some of them if anyone is interested in making use of it.
>>
>> On Wed, May 17, 2017 at 1:55 AM, Niels Basjes <Ni...@basjes.nl> wrote:
>> > Hi,
>> >
>> > Just now I ran into an obscure problem in the 1.8.2 release I thought I
>> had
>> > already fixed.
>> > Researching the issue I found that some of the fixes that have been
>> > committed to the master over the last few months have not been included
>> in
>> > this release.
>> >
>> > I myself made some of those fixes and I would really like to know: What
>> > went wrong? What did I do wrong?
>> >
>> > To get some insight I simply did a diff of the CHANGELOG and found these
>> to
>> > be missing:
>> >
>> > AVRO-1993: C++ Byte ordering macro does not work on FreeBSD (thiru)
>> > AVRO-1975: Upgrade java dependencies (gabor)
>> > AVRO-1960: Add log4j properties for avro-tools
>> > AVRO-1748. Add Snappy Compression to C++ DataFile (J. Langley via thiru)
>> > AVRO-1626: C#: Fix Avro.pref build error. (Naruto Takahashi via blue)
>> > AVRO-1966: Java: Fix NPE When copying builder with nullable record.
>> > (Niels Basjes)
>> > AVRO-1967: Java: Fix NPE when calling getXyzBuilder on instance where
>> > the xyz is null (Niels Basjes)
>> > AVRO-1970: Java: Flaky test: TestInputBytes. (Gabor Szadovszky via
>> tomwhite)
>> > AVRO-1881: Java: Avro (Java) Memory Leak when reusing JsonDecoder
>> > instance. (Nandor Kollar via tomwhite)
>> > AVRO-1954: Java: Schema.Field.defaultVal() generates: Unknown datum
>> > type (Nandor Kollar via tomwhite)
>> > AVRO-1930: JsonParser doesn't handle integer scientific notation
>> > (Pietro Cerutti via thiru)
>> > AVRO-1912: C++ Resolving Decoding doesn't work if element removed from
>> > record in array. (via thiru)
>> > AVRO-1866. JsonNullFormatter fwd-declared as class, defined as struct
>> > ( Pietro Cerutti via thiru)
>> > AVRO-1750. GenericDatum API behavior breaking change (thiru)
>> > AVRO-1995: JSON Parser does not properly check current state (Victor
>> > Mota via thiru)
>> > AVRO-1216. Setting precision for the output stream (John McClean via
>> thiru)
>> > AVRO-1937: C++ generator for recursive structure crashes (thiru)
>> > AVRO-1892. C++ library cannot parse unions with default values (Hua
>> > Zhang via thiru)
>> > AVRO-1994. C++ Code Generator Generates Invalid Code if Field is of
>> > type Null (Darryl Green via thiru)
>> > AVRO-1997. Avro Field.defaultVal broken for Fixed fields. (Zoltan
>> > Farkasi via thiru)
>> > AVRO-1838: Java: Update checkstyle to catch trailing whitespace.
>> > (nielsbasjes via blue)
>> >
>> >
>> > Since several of these are NPE/crashes area I think we should consider
>> > getting 1.8.3 out quicker than what we would normally do.
>> >
>> > --
>> > Best regards / Met vriendelijke groeten,
>> >
>> > Niels Basjes
>>
>>
>>
>> --
>> busbey
>>
>
>
>
> --
> Ryan Blue
> Software Engineer
> Netflix
--
busbey
Re: Why are there so many fixes missing in the 1.8.2 release ?!?
Posted by Ryan Blue <rb...@netflix.com.INVALID>.
I didn't think that the only way to get something into a release was to
backport it immediately. When I was RM, I would look through the new
commits on master and backport what I thought was safe. That step is in the
release documentation (step 7
<https://cwiki.apache.org/confluence/display/AVRO/How+To+Release>).
In this case, the 1.8.2 release was delayed after the first few votes
failed, so I think it was a reasonable call to get the release out... but
it would be nice to get a 1.8.3 out as well to pick up the new fixes.
rb
On Thu, May 18, 2017 at 2:12 PM, Sean Busbey <bu...@cloudera.com> wrote:
> (Repeating my comments from the comment on the 1.8.2 release jira):
>
> Master is targetting 1.9.0 now, if the committer of the fix doesn't
> cherry pick back to branch 1.8 or branch 1.7 before closing then those
> things won't get into new 1.8 or 1.7 releases.
>
> branch-1.8 broke off of master in December 2015, so for example
> AVRO-1966 looks like it was committed only to master but the fix
> version was set to 1.8.2 instead of 1.9.0.
>
> I have some release process notes I use in Apache HBase to check how
> well JIRA and git mesh up with each other, we could try making use of
> some of them if anyone is interested in making use of it.
>
> On Wed, May 17, 2017 at 1:55 AM, Niels Basjes <Ni...@basjes.nl> wrote:
> > Hi,
> >
> > Just now I ran into an obscure problem in the 1.8.2 release I thought I
> had
> > already fixed.
> > Researching the issue I found that some of the fixes that have been
> > committed to the master over the last few months have not been included
> in
> > this release.
> >
> > I myself made some of those fixes and I would really like to know: What
> > went wrong? What did I do wrong?
> >
> > To get some insight I simply did a diff of the CHANGELOG and found these
> to
> > be missing:
> >
> > AVRO-1993: C++ Byte ordering macro does not work on FreeBSD (thiru)
> > AVRO-1975: Upgrade java dependencies (gabor)
> > AVRO-1960: Add log4j properties for avro-tools
> > AVRO-1748. Add Snappy Compression to C++ DataFile (J. Langley via thiru)
> > AVRO-1626: C#: Fix Avro.pref build error. (Naruto Takahashi via blue)
> > AVRO-1966: Java: Fix NPE When copying builder with nullable record.
> > (Niels Basjes)
> > AVRO-1967: Java: Fix NPE when calling getXyzBuilder on instance where
> > the xyz is null (Niels Basjes)
> > AVRO-1970: Java: Flaky test: TestInputBytes. (Gabor Szadovszky via
> tomwhite)
> > AVRO-1881: Java: Avro (Java) Memory Leak when reusing JsonDecoder
> > instance. (Nandor Kollar via tomwhite)
> > AVRO-1954: Java: Schema.Field.defaultVal() generates: Unknown datum
> > type (Nandor Kollar via tomwhite)
> > AVRO-1930: JsonParser doesn't handle integer scientific notation
> > (Pietro Cerutti via thiru)
> > AVRO-1912: C++ Resolving Decoding doesn't work if element removed from
> > record in array. (via thiru)
> > AVRO-1866. JsonNullFormatter fwd-declared as class, defined as struct
> > ( Pietro Cerutti via thiru)
> > AVRO-1750. GenericDatum API behavior breaking change (thiru)
> > AVRO-1995: JSON Parser does not properly check current state (Victor
> > Mota via thiru)
> > AVRO-1216. Setting precision for the output stream (John McClean via
> thiru)
> > AVRO-1937: C++ generator for recursive structure crashes (thiru)
> > AVRO-1892. C++ library cannot parse unions with default values (Hua
> > Zhang via thiru)
> > AVRO-1994. C++ Code Generator Generates Invalid Code if Field is of
> > type Null (Darryl Green via thiru)
> > AVRO-1997. Avro Field.defaultVal broken for Fixed fields. (Zoltan
> > Farkasi via thiru)
> > AVRO-1838: Java: Update checkstyle to catch trailing whitespace.
> > (nielsbasjes via blue)
> >
> >
> > Since several of these are NPE/crashes area I think we should consider
> > getting 1.8.3 out quicker than what we would normally do.
> >
> > --
> > Best regards / Met vriendelijke groeten,
> >
> > Niels Basjes
>
>
>
> --
> busbey
>
--
Ryan Blue
Software Engineer
Netflix
Re: Why are there so many fixes missing in the 1.8.2 release ?!?
Posted by Sean Busbey <bu...@cloudera.com>.
(Repeating my comments from the comment on the 1.8.2 release jira):
Master is targetting 1.9.0 now, if the committer of the fix doesn't
cherry pick back to branch 1.8 or branch 1.7 before closing then those
things won't get into new 1.8 or 1.7 releases.
branch-1.8 broke off of master in December 2015, so for example
AVRO-1966 looks like it was committed only to master but the fix
version was set to 1.8.2 instead of 1.9.0.
I have some release process notes I use in Apache HBase to check how
well JIRA and git mesh up with each other, we could try making use of
some of them if anyone is interested in making use of it.
On Wed, May 17, 2017 at 1:55 AM, Niels Basjes <Ni...@basjes.nl> wrote:
> Hi,
>
> Just now I ran into an obscure problem in the 1.8.2 release I thought I had
> already fixed.
> Researching the issue I found that some of the fixes that have been
> committed to the master over the last few months have not been included in
> this release.
>
> I myself made some of those fixes and I would really like to know: What
> went wrong? What did I do wrong?
>
> To get some insight I simply did a diff of the CHANGELOG and found these to
> be missing:
>
> AVRO-1993: C++ Byte ordering macro does not work on FreeBSD (thiru)
> AVRO-1975: Upgrade java dependencies (gabor)
> AVRO-1960: Add log4j properties for avro-tools
> AVRO-1748. Add Snappy Compression to C++ DataFile (J. Langley via thiru)
> AVRO-1626: C#: Fix Avro.pref build error. (Naruto Takahashi via blue)
> AVRO-1966: Java: Fix NPE When copying builder with nullable record.
> (Niels Basjes)
> AVRO-1967: Java: Fix NPE when calling getXyzBuilder on instance where
> the xyz is null (Niels Basjes)
> AVRO-1970: Java: Flaky test: TestInputBytes. (Gabor Szadovszky via tomwhite)
> AVRO-1881: Java: Avro (Java) Memory Leak when reusing JsonDecoder
> instance. (Nandor Kollar via tomwhite)
> AVRO-1954: Java: Schema.Field.defaultVal() generates: Unknown datum
> type (Nandor Kollar via tomwhite)
> AVRO-1930: JsonParser doesn't handle integer scientific notation
> (Pietro Cerutti via thiru)
> AVRO-1912: C++ Resolving Decoding doesn't work if element removed from
> record in array. (via thiru)
> AVRO-1866. JsonNullFormatter fwd-declared as class, defined as struct
> ( Pietro Cerutti via thiru)
> AVRO-1750. GenericDatum API behavior breaking change (thiru)
> AVRO-1995: JSON Parser does not properly check current state (Victor
> Mota via thiru)
> AVRO-1216. Setting precision for the output stream (John McClean via thiru)
> AVRO-1937: C++ generator for recursive structure crashes (thiru)
> AVRO-1892. C++ library cannot parse unions with default values (Hua
> Zhang via thiru)
> AVRO-1994. C++ Code Generator Generates Invalid Code if Field is of
> type Null (Darryl Green via thiru)
> AVRO-1997. Avro Field.defaultVal broken for Fixed fields. (Zoltan
> Farkasi via thiru)
> AVRO-1838: Java: Update checkstyle to catch trailing whitespace.
> (nielsbasjes via blue)
>
>
> Since several of these are NPE/crashes area I think we should consider
> getting 1.8.3 out quicker than what we would normally do.
>
> --
> Best regards / Met vriendelijke groeten,
>
> Niels Basjes
--
busbey