Great point. I would eventually like to remove the vote overhead as well. It is required per ASF policy but I am actually taking a look around to work around this. I took it as monthly because it seems to be pretty enough given my experience of releasing Spark 3.5.6 via automated GitHub Actions.
It's more to try it out and see how it goes actually so I think we won't have to worry too much. I also don't want us to strictly force the monthly release - we could skip a couple if there's anything happening. If things don't go well, we can always change / adjust timelines, etc. On Wed, 2 Jul 2025 at 20:39, Mark Hamstra <markhams...@gmail.com> wrote: > On Tue, Jul 1, 2025 at 9:42 PM Hyukjin Kwon <gurwls...@apache.org> wrote: > > > > > 1. Since we "release" the preview, we will go through the VOTE > process. What is the expected overhead on doing this monthly? (Maybe this > would be coupled with the questions below.) > > > > We have to vote for every preview every month for now. We can try and > see how it goes. > > The voting requirement does make me question the overhead as well. I'm > not sure that we can expect the number of PMC members necessary for a > valid vote to give a meaningful release review every month. That would > leave us with automated preview releases with invalid or failed > release votes, or perhaps even worse, preview-releases that have been > rubber-stamped without meaningful review. Beyond naming/accounting > details such as whether the next preview release after preview-n fails > to pass the vote threshold is a potentially confusing repeat of > preview-n or automatically becomes preview-n+1 or preview-n+0.1 or > something, a build up of failed, non-released "releases" would seem to > create its own uncertainty, friction and overhead. > > Given arguendo that the span between actual releases is currently too > long and that the other extreme of an automated release after every > commit would be too short, what is the basis for monthly instead of > maybe something like bi-monthly or quarterly being the right > preview-release cadence? > > --------------------------------------------------------------------- > To unsubscribe e-mail: dev-unsubscr...@spark.apache.org > >
