IMHO it's probably better to avoid trying to figure out a workaround if that is the "policy" of ASF.
Btw, I guess the main point here is, what is the definition of "acceptable" release. For example, do we feel overloaded to just verify the signature per month? I think we wouldn't. The reason the topic of overhead on the voting came up is because we are not very clear about what the shape of release we want to have for previews. IIUC about SPIP (also answers from Hyukjin w.r.t. my questions), the demand of having preview releases is closer to the demand we want to "tag" the snapshot at some point and release artifacts so that people (especially early adopters and 3rd parties) do not need to struggle with how to pull snapshot artifacts, or even have to build on their own. If that is the case and we are happy with that direction, maybe the fact CI passes would be enough to give +1 to the release along with signature verification. If we want to provide specific meaning to the preview release (e.g. we release preview for feature A being completed), it's probably non-trivial to set the timeline in prior and it has to be flexible rather than specific interval. But if we are on the same page that it's really a pain to play with a snapshot and we want to provide some checkpointed artifacts in the middle of development, I think this is worth giving a try. At least it is not a one way door and interval is not a strict one which can change later upon more lightweight discussion. On Thu, Jul 3, 2025 at 8:59 AM Hyukjin Kwon <gurwls...@apache.org> wrote: > 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 >> >>
