feat: send email on ddl change

[gracecluvohio]

What changes were proposed in this PR?

This PR adds a workflow that automatically sends an email notifying developers on DDL change.

Please note that we will need to add GitHub secrets MAIL_USERNAME and MAIL_PASSWORD to specify which email to send the email from.

Any related issues, documentation, discussions?

Closes #4166

How was this PR tested?

Tested on my private repository.

Was this PR authored or co-authored using generative AI tooling?

Co-authored using: Claude Code (Sonnet 4.6)

[chenlica]

@bobbai00 : please work with @gracecluvohio on this task.

[bobbai00]

Dear @parshimers ,

I would like to know if this is a good practice. If so, what should be the email sender for such emails? I searched for things like noreply@texera.apache.org, but seems there is no such mechanism.

[parshimers]

Dear @parshimers ,

I would like to know if this is a good practice. If so, what should be the email sender for such emails? I searched for things like noreply@texera.apache.org, but seems there is no such mechanism.

Hey Jiadong,
I think in general it is a good practice. For some robot emails I usually just make the reply-to address the dev@ address, since that's where it's going. However, I think an even better practice would be making major changes that are backwards-incompatible more of an community decision, taking place on the dev@ list. Take for example SPIP in Spark, or JEP in OpenJDK. In this way, any community member that is following the development of the project wouldn't be surprised that a breaking change was merged, because they would either be involved or at least watching. I have tried to do this in AsterixDB, and to help instill a culture of basically not breaking the userland unless there is a clear consensus as to what should be broken and why, via the APE process. It's definitely not perfect though and takes time, culture is a multifaceted thing that no one person can change.

Hope that helps,

• Ian

[gracecluvohio]

Hello @chenlica and @bobbai00 ,

What do you think about making the SQL DDL changes a community wide discussion instead? Perhaps we could notify developers via the dev mail list before a DDL change is merged, rather than after. That way developers have a say, or are at least aware, before a breaking change is merged.

[bobbai00]

Dear @parshimers ,
I would like to know if this is a good practice. If so, what should be the email sender for such emails? I searched for things like noreply@texera.apache.org, but seems there is no such mechanism.

Hey Jiadong, I think in general it is a good practice. For some robot emails I usually just make the reply-to address the dev@ address, since that's where it's going. However, I think an even better practice would be making major changes that are backwards-incompatible more of an community decision, taking place on the dev@ list. Take for example SPIP in Spark, or JEP in OpenJDK. In this way, any community member that is following the development of the project wouldn't be surprised that a breaking change was merged, because they would either be involved or at least watching. I have tried to do this in AsterixDB, and to help instill a culture of basically not breaking the userland unless there is a clear consensus as to what should be broken and why, via the APE process. It's definitely not perfect though and takes time, culture is a multifaceted thing that no one person can change.

Hope that helps,

• Ian

Thank you Ian. In this case, I think we can close this PR and define the protocol similar to Spark's SPIP.

[bobbai00]

Hello @chenlica and @bobbai00 ,

What do you think about making the SQL DDL changes a community wide discussion instead? Perhaps we could notify developers via the dev mail list before a DDL change is merged, rather than after. That way developers have a say, or are at least aware, before a breaking change is merged.

Hi @gracecluvohio and @chenlica ,

According to Ian's comment, I am leaning towards closing this PR and defining something similar to https://spark.apache.org/improvement-proposals.html. For all the changes that are non-backward-compatible, we should let developers follow this protocol.

What do you guys think?

[gracecluvohio]

Hello @chenlica and @bobbai00 ,
What do you think about making the SQL DDL changes a community wide discussion instead? Perhaps we could notify developers via the dev mail list before a DDL change is merged, rather than after. That way developers have a say, or are at least aware, before a breaking change is merged.

Hi @gracecluvohio and @chenlica ,

According to Ian's comment, I am leaning towards closing this PR and defining something similar to https://spark.apache.org/improvement-proposals.html. For all the changes that are non-backward-compatible, we should let developers follow this protocol.

What do you guys think?

I'm not sure. On one hand, I think having a proposal system could be helpful to ensure that developers have a say in breaking changes. However, it also seems like a very involved, lengthy process for PRs with small DDL changes. I'm not sure if the whole community needs to be involved in the review of such PRs; they just need to be notified of one, so they can keep their local instance operational.

I'd like to hear what @chenlica thinks though.

[chenlica]

I prefer a protocol that can allow us to make DDL changes quickly, as in an "optimistic commit protocol." When our community gets big enough, we can use a more conservative approach.

[gracecluvohio]

@chenlica @bobbai00 Should we move forward with making a bot account then? I can do this for now. This is a temporary fix for what I would want to do, long term we could use Flyway or Liquibase to manage database version control.

[chenlica]

@bobbai00 Please make a decision.