I agree with Adar regarding the fix, we should avoid knowingly releasing a version with an issue we can't fix down the road due to backwards-compatibility issues.
I also agree with Alexey that we can revert the change introducing live_row_count instead of waiting for the fix, at least if it takes too long. I think we can revert the commit in branch-1.11.x only though, that way we don't need to re-add it in master. Either way, we'll need to cut an RC3 if we want to avoid a breaking change in 1.12, so in case KUDU-2980 and gerrit/14507 are close to be merged, we might as well wait for them to be merged before cutting RC3. I would let Alexey to decide which approach to take though as he's the RM. On Tue, Oct 22, 2019 at 01:30:41PM -0700, Alexey Serbin wrote: > I think we can cut another RC if we really think that incorporating these > fixes makes the release candidate more robust and sound. I'm not sure what > is time-based limit there, but it would be great if we could wrap it up in > one week or so. > > From the other side, as PlanB we could rollback the changes that > http://gerrit.cloudera.org:8080/14507 follows up and update the release > notes regarding the live_row_count metrics to make sure we don't introduce > any incompatibility. We can re-apply the reverted patches in the master > branch and continue developing and fixing related bugs (if any), scheduling > releasing them in Kudu 1.12 with less hustle. We can also schedule fixes > for KUDU-2980 to be in 1.12 since it doesn't look like a release blocker > (1.10 is also affected by the issue, so it's not a regression introduced in > 1.11 anyways). > > Which path is more preferable? > > We can think of other options as well. > > > Thanks, > > Alexey > > On Tue, Oct 22, 2019 at 10:46 AM Adar Lieber-Dembo > <a...@cloudera.com.invalid> wrote: > > > +0 > > > > Built on Ubuntu 18.04 and CentOS 6.6. Ran DEBUG tests in slow mode. No > > failures. > > > > I do wish the release incorporated the fix for KUDU-2980, but that > > hasn't even been published to CR yet. Plus it won't break backwards > > compatibility if we fix it later. > > > > On the other hand, http://gerrit.cloudera.org:8080/14507 must get in > > now; otherwise there will be backwards compat issues if it is merged > > for 1.12.0. What do other people think? > > > > > > > > > > On Fri, Oct 18, 2019 at 12:53 PM Alexey Serbin > > <aser...@cloudera.com.invalid> wrote: > > > > > > Hello Kudu devs! > > > > > > The Apache Kudu team is happy to announce the second release candidate > > for > > > Apache Kudu 1.11.0. > > > > > > Apache Kudu 1.11.0 is a minor release that offers many improvements and > > > fixes > > > since the prior release. > > > > > > This is a source-only release. The artifacts have been staged here: > > > https://dist.apache.org/repos/dist/dev/kudu/1.11.0-RC2/ > > > > > > Java convenience binaries in the form of a Maven repository are staged > > here: > > > https://repository.apache.org/content/repositories/orgapachekudu-1040/ > > > > > > It is tagged in Git as 1.11.0-RC1 and the corresponding hash is the > > > following: > > > > > https://gitbox.apache.org/repos/asf?p=kudu.git;a=commit;h=f6623f527b6c7e95b84d6f719fa1cb9eff4ebd29 > > > > > > The release notes can be found here: > > > > > https://github.com/apache/kudu/blob/branch-1.11.x/docs/release_notes.adoc > > > > > > The KEYS file to verify the artifact signatures can be found here: > > > https://dist.apache.org/repos/dist/release/kudu/KEYS > > > > > > I'd suggest going through the README and the release notes, building > > Kudu, > > > and > > > running the unit tests. Testing out the Maven repo would also be > > > appreciated. > > > > > > The vote will run until Wed Oct 23 11:00:00 PDT 2019. This is more than > > > usual 72 hours from the time of sending out this e-mail message because > > > of the weekend. > > > > > > > > > Thanks, > > > Alexey > >
