[Feedback][Release] Some feedback when releasing v1.22.0

[Danny Chan <yu...@gmail.com>]

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

Re: [Feedback][Release] Some feedback when releasing v1.22.0

[Julian Hyde <jh...@apache.org>]

+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 <mm...@apache.org> 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
> mmior@apache.org
> 
> Le ven. 6 mars 2020 à 09:54, Danny Chan <yu...@gmail.com> 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

Re: [Feedback][Release] Some feedback when releasing v1.22.0

[Michael Mior <mm...@apache.org>]

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
mmior@apache.org

Le ven. 6 mars 2020 à 09:54, Danny Chan <yu...@gmail.com> 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

Re: [Feedback][Release] Some feedback when releasing v1.22.0

[Julian Hyde <jh...@apache.org>]

My apologies. I had forgotten that “git fetch” does not fully synchronize tags.

> On Mar 10, 2020, at 5:23 PM, Danny Chan <da...@apache.org> wrote:
> 
> I already fix that
> 
> Julian Hyde <jh...@apache.org>于2020年3月11日 周三上午2:00写道：
> 
>> Danny,
>> 
>> Can you fix the tag please?
>> 
>> Julian
>> 
>> 
>>> On Mar 6, 2020, at 10:26 AM, Vladimir Sitnikov <
>> sitnikov.vladimir@gmail.com> wrote:
>>> 
>>>> The RexNode normalization and project names remove from digest did
>> change
>>> a lot of plan from the Apache Flink side
>>> 
>>> Hey Danny, I see it is dissatisfying, however, it is really sad you have
>>> never revealed which plans required changes and why.
>>> 
>>>> The java doc doesn’t distinguish main API and test API, they are just
>>> together [1]
>>> 
>>> I do not see "test API" there. Can you please clarify?
>>> 
>>>> • The calcite-core does not publish the test sources now, should we add
>> it
>>> back ?
>>> 
>>> We should **drop** publishing test artifacts via classifiers.
>>> The problem with classifier-style approach is those artifacts can't
>> declare
>>> their dependencies.
>>> 
>>> We have already discussed it, and there was an agreement that we could
>>> extract calcite-test-framework or something like that.
>>> It could come as a separate artifact with its own properly-declared
>>> dependencies, sources, etc, etc.
>>> 
>>>> 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
>>> 
>>> I think we should stop adding (contributor name) in the commit message.
>>> Git does have a proper field for the author's name. Of course committers
>>> need to ensure they don't overwrite that field by accident.
>>> 
>>> Now we have Gradle, so we could even automate certain tasks.
>>> For instance, it could process Git history and build a list of
>>> contributors, etc, etc.
>>> 
>>> 
>>>> 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
>>> 
>>> What do you mean by "RC artifacts removed"?
>>> Release plugin does svn **MOVE** from repos/dist/dev to
>> repos/dist/release/
>>> This makes it clear that the release artifacts are the same as the ones
>>> used for vote.
>>> 
>>> 
>>> Vladimir
>> 
>> 

Re: [Feedback][Release] Some feedback when releasing v1.22.0

[Danny Chan <da...@apache.org>]

I already fix that

Julian Hyde <jh...@apache.org>于2020年3月11日 周三上午2:00写道：

> Danny,
>
> Can you fix the tag please?
>
> Julian
>
>
> > On Mar 6, 2020, at 10:26 AM, Vladimir Sitnikov <
> sitnikov.vladimir@gmail.com> wrote:
> >
> >> The RexNode normalization and project names remove from digest did
> change
> > a lot of plan from the Apache Flink side
> >
> > Hey Danny, I see it is dissatisfying, however, it is really sad you have
> > never revealed which plans required changes and why.
> >
> >> The java doc doesn’t distinguish main API and test API, they are just
> > together [1]
> >
> > I do not see "test API" there. Can you please clarify?
> >
> >> • The calcite-core does not publish the test sources now, should we add
> it
> > back ?
> >
> > We should **drop** publishing test artifacts via classifiers.
> > The problem with classifier-style approach is those artifacts can't
> declare
> > their dependencies.
> >
> > We have already discussed it, and there was an agreement that we could
> > extract calcite-test-framework or something like that.
> > It could come as a separate artifact with its own properly-declared
> > dependencies, sources, etc, etc.
> >
> >> 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
> >
> > I think we should stop adding (contributor name) in the commit message.
> > Git does have a proper field for the author's name. Of course committers
> > need to ensure they don't overwrite that field by accident.
> >
> > Now we have Gradle, so we could even automate certain tasks.
> > For instance, it could process Git history and build a list of
> > contributors, etc, etc.
> >
> >
> >> 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
> >
> > What do you mean by "RC artifacts removed"?
> > Release plugin does svn **MOVE** from repos/dist/dev to
> repos/dist/release/
> > This makes it clear that the release artifacts are the same as the ones
> > used for vote.
> >
> >
> > Vladimir
>
>

Re: [Feedback][Release] Some feedback when releasing v1.22.0

[Julian Hyde <jh...@apache.org>]

Danny,

Can you fix the tag please?

Julian


> On Mar 6, 2020, at 10:26 AM, Vladimir Sitnikov <si...@gmail.com> wrote:
> 
>> The RexNode normalization and project names remove from digest did change
> a lot of plan from the Apache Flink side
> 
> Hey Danny, I see it is dissatisfying, however, it is really sad you have
> never revealed which plans required changes and why.
> 
>> The java doc doesn’t distinguish main API and test API, they are just
> together [1]
> 
> I do not see "test API" there. Can you please clarify?
> 
>> • The calcite-core does not publish the test sources now, should we add it
> back ?
> 
> We should **drop** publishing test artifacts via classifiers.
> The problem with classifier-style approach is those artifacts can't declare
> their dependencies.
> 
> We have already discussed it, and there was an agreement that we could
> extract calcite-test-framework or something like that.
> It could come as a separate artifact with its own properly-declared
> dependencies, sources, etc, etc.
> 
>> 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
> 
> I think we should stop adding (contributor name) in the commit message.
> Git does have a proper field for the author's name. Of course committers
> need to ensure they don't overwrite that field by accident.
> 
> Now we have Gradle, so we could even automate certain tasks.
> For instance, it could process Git history and build a list of
> contributors, etc, etc.
> 
> 
>> 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
> 
> What do you mean by "RC artifacts removed"?
> Release plugin does svn **MOVE** from repos/dist/dev to repos/dist/release/
> This makes it clear that the release artifacts are the same as the ones
> used for vote.
> 
> 
> Vladimir

Re: [Feedback][Release] Some feedback when releasing v1.22.0

[Vladimir Sitnikov <si...@gmail.com>]

>The RexNode normalization and project names remove from digest did change
a lot of plan from the Apache Flink side

Hey Danny, I see it is dissatisfying, however, it is really sad you have
never revealed which plans required changes and why.

>The java doc doesn’t distinguish main API and test API, they are just
together [1]

I do not see "test API" there. Can you please clarify?

>• The calcite-core does not publish the test sources now, should we add it
back ?

We should **drop** publishing test artifacts via classifiers.
The problem with classifier-style approach is those artifacts can't declare
their dependencies.

We have already discussed it, and there was an agreement that we could
extract calcite-test-framework or something like that.
It could come as a separate artifact with its own properly-declared
dependencies, sources, etc, etc.

>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

I think we should stop adding (contributor name) in the commit message.
Git does have a proper field for the author's name. Of course committers
need to ensure they don't overwrite that field by accident.

Now we have Gradle, so we could even automate certain tasks.
For instance, it could process Git history and build a list of
contributors, etc, etc.


>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

What do you mean by "RC artifacts removed"?
Release plugin does svn **MOVE** from repos/dist/dev to repos/dist/release/
This makes it clear that the release artifacts are the same as the ones
used for vote.


Vladimir