+1 to everything Michael said. Also… This release was hard because we let the date slip. Therefore there were more changes for Danny to deal with, more commit messages to edit, more regressions.
We have been trying hard to keep the release tempo to two months. Let’s continue to strive for that. Having a roster of release managers agreed in advance seem to help with that. As we have discussed, the next release should be sooner than two months. Regarding commit messages. Does the responsibility lie on the code author, the committer, or the release manager? The answer is all three. Ideally the code author write a perfect commit message first time, but in practice the committer needs to help, and not all committers do a perfect job, so the release manager is the last resort. The release manager has the unique job of organizing the work that has gone into a release into something that can be consumed by the public. That means picking the main features to highlight in the release notes, re-ordering commits into groups, and copy-editing commit messages. Sorry it’s a lot of work, but it’s valuable to our users and no one else can do it. Let’s keep releases down to 2 months and it will be less work for the next release manager. Vladimir suggested in another thread that (paraphrasing) building a release was automated, so why did we need a vote? My answer is that we aim to automate as much as possible, but we have to verify that the automation worked. In most releases it shouldn’t be too much effort. Everyone who votes on a release seems to have a different set of checks, and when we combine those checks, the result is that we get to 99.9% probability that we have a good release. Special thanks to committers from downstream projects who run their project’s test suite on our RCs. Thanks for being RM, Danny! Your email about javadoc in chinese made me chuckle. Every RM manages to find a new flaw in the process. And so we get stronger. Julian > On Mar 6, 2020, at 8:15 AM, Michael Mior <[email protected]> wrote: > > Thanks again Danny for managing what proved to be a very complicated > release! A few of my thoughts below: > > - Yes, we should try to write good commit messages to remove the > burden from the release manager > - Personally I think we should use tags for releases consistent with > what we have used in the past. I assume we can configure Gradle's > release plugin to do so. > - I personally would like to have the test sources still published > since I use them in my Calcite notebooks project > (https://github.com/michaelmior/calcite-notebooks) > -- > Michael Mior > [email protected] > > Le ven. 6 mars 2020 à 09:54, Danny Chan <[email protected]> a écrit : >> >> About how/when the code is suitable for a release >> >> 1.22.0 is a huge release and we have many bug-fixes and improvements, but >> also we changed a lot of code: >> >> >> • The RexNode normalization and project names remove from digest did change >> a lot of plan from the Apache Flink side >> • Personally I fixed about 10+ bugs when I do a pre-validation for Apache >> Flink 1.11.0-SNAPSHOT locally >> >> I believe the Calcite code is always in good quality and shape, but these >> bugs still there, we need to find a way to reduce these bugs. >> >> Some fellows suggest to introduce a daily tests for other downstream >> projects, maybe a good idea ~ >> >> About the release tag format >> The release tag now changes from pattern calcite-x.y.z to rel/vx.y.z, which >> is done automatically by the release plugin of current Gradle, we should >> make a decision which pattern we should use ~ >> >> About the release note >> Some fellows think that some of the commit messages are not that >> readable/understandable, I have some thoughts here ~ >> >> >> • It’s not easy to keep every commit message readable for the release >> manager, we better do this when we merge the code >> • We may need some part in the future to show the known issues/bugs which is >> introduced in current release >> • Do we need to put the credit (commit name) after each commit message ? It >> seems many projects put the credits in the last part together of the release >> note >> >> >> About the release plugin >> >> I found some problems of the current release plugin work-flow(personal >> feeling): >> >> • The RC artifacts was removed when I do the release, which actually I think >> should not do, one awkward thing is that my network sucks, I failed in the >> last step, so the RC artifacts removed but the release failed ~ >> • The java doc doesn’t distinguish main API and test API, they are just >> together [1] ~ >> • The calcite-core does not publish the test sources now, should we add it >> back ? >> >> [1] https://calcite.apache.org/javadocAggregate/ >> >> Best, >> Danny Chan
