I am working on it at https://github.com/apache/spark/pull/51122. Some emails might be sent for RC 3.5.7 for testing purposes. Please ignore them :-). I will reply to individual email as well to avoid confusion.
On Thu, 5 Jun 2025 at 20:07, Yang Jie <yangji...@apache.org> wrote: > Option 1 +1, thank you, Hyukjin, for the efforts you've put into this. > > On 2025/06/06 02:59:32 Jungtaek Lim wrote: > > Thanks for the confirmation. That sounds great as long as the ASF account > > information is required per run and never be stored somewhere after the > run. > > > > 2025년 6월 6일 (금) 오전 11:39, Hyukjin Kwon <gurwls...@apache.org>님이 작성: > > > > > When you run the GitHub Actions to release, it requires you to specify > an > > > ASF account and password in GitHub Secrets. So I plan to use that to > send > > > an email. > > > I will probably add a note that the email was auto generated .. > > > > > > On Fri, 6 Jun 2025 at 11:37, Jungtaek Lim < > kabhwan.opensou...@gmail.com> > > > wrote: > > > > > >> One question: is it possible for the automation to send the mail on > > >> behalf of release manager? Or will we simply send the mail as > specific mail > > >> account (mostly dedicated one for automated)? > > >> > > >> Maybe latter doesn’t even matter, but it might be less clear about > who is > > >> driving the release, from automated RC mail. > > >> > > >> 2025년 6월 6일 (금) 오전 2:09, Wenchen Fan <cloud0...@gmail.com>님이 작성: > > >> > > >>> +1 for email automation! > > >>> > > >>> On Thu, Jun 5, 2025 at 8:22 AM Yuanjian Li <xyliyuanj...@gmail.com> > > >>> wrote: > > >>> > > >>>> +1 for option 1. > > >>>> > > >>>> Seems the only downside of option 1 is that some RC numbers may be > > >>>> non-sequential. > > >>>> > > >>>> Dongjoon Hyun <dongjoon.h...@gmail.com> 于2025年6月5日周四 07:57写道： > > >>>> > > >>>>> +1 for the proposal, Hyukjin. Thank you for the whole and seamless > > >>>>> migration toward this direction. > > >>>>> > > >>>>> Please make it sure that we explicitly show the human release > manager > > >>>>> name and email address (instead of bot sender) in the generated > email. > > >>>>> That's the only concern I have. > > >>>>> > > >>>>> Thanks, > > >>>>> Dongjoon. > > >>>>> > > >>>>> > > >>>>> > > >>>>> On Wed, Jun 4, 2025 at 9:32 PM Mridul Muralidharan < > mri...@gmail.com> > > >>>>> wrote: > > >>>>> > > >>>>>> > > >>>>>> We can always invalidate the vote with -1 in case it is found > to be > > >>>>>> sent incorrectly ... As long as the automation does not end up > generating a > > >>>>>> tonne of mails, that is, it should be fairly manageable :) > > >>>>>> I am in favor of automating it with option 1. > > >>>>>> > > >>>>>> Thanks for driving this Hyukjin ! > > >>>>>> > > >>>>>> Regards, > > >>>>>> Mridul > > >>>>>> > > >>>>>> > > >>>>>> On Wed, Jun 4, 2025 at 6:53 PM Hyukjin Kwon <gurwls...@apache.org > > > > >>>>>> wrote: > > >>>>>> > > >>>>>>> Hi all, > > >>>>>>> > > >>>>>>> As some of you may know, I’ve been working on automating the > Spark > > >>>>>>> release process (release.yml > > >>>>>>> <https://github.com/apache/spark/actions/workflows/release.yml > >). > > >>>>>>> The basic steps are done, and I’m now looking into automating > some of the > > >>>>>>> remaining manual tasks. > > >>>>>>> > > >>>>>>> One such task is sending the email to start the vote for an RC. > I’d > > >>>>>>> like to automate this step as well. > > >>>>>>> > > >>>>>>> The potential downside is that, in corner cases, an incorrect RC > > >>>>>>> might still trigger the vote email (even though failures should > be caught > > >>>>>>> earlier). To handle this, I propose we send the email > automatically and > > >>>>>>> rely on the community to help verify the RC. If something is > wrong, we can > > >>>>>>> simply cut a new RC - which is now much easier to do. > > >>>>>>> > > >>>>>>> Alternatively, a more conservative option is to generate a draft > of > > >>>>>>> the email in the build log and let the release manager copy and > send it > > >>>>>>> manually. > > >>>>>>> > > >>>>>>> I personally prefer the first approach, but I’d like to hear what > > >>>>>>> others think. > > >>>>>>> > > >>>>>>> > > > > --------------------------------------------------------------------- > To unsubscribe e-mail: dev-unsubscr...@spark.apache.org > >
