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 <[email protected]> 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 <[email protected]> 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 <[email protected]> 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
