I'm more than willing to help migrate the scripts as part of either this release or the next.
It sounds like there is a consensus developing around changing the process -- should we hold off on the 2.1.2 release or roll this into the next one? On Mon, Sep 18, 2017 at 7:37 PM, Marcelo Vanzin <van...@cloudera.com> wrote: > +1 to this. There should be a script in the Spark repo that has all > the logic needed for a release. That script should take the RM's key > as a parameter. > > if there's a desire to keep the current Jenkins job to create the > release, it should be based on that script. But from what I'm seeing > there are currently too many unknowns in the release process. > > On Mon, Sep 18, 2017 at 4:55 PM, Ryan Blue <rb...@netflix.com.invalid> > wrote: > > I don't understand why it is necessary to share a release key. If this is > > something that can be automated in a Jenkins job, then can it be a script > > with a reasonable set of build requirements for Mac and Ubuntu? That's > the > > approach I've seen the most in other projects. > > > > I'm also not just concerned about release managers. Having a key stored > > persistently on outside infrastructure adds the most risk, as Luciano > noted > > as well. We should also start publishing checksums in the Spark VOTE > thread, > > which are currently missing. The risk I'm concerned about is that if the > key > > were compromised, it would be possible to replace binaries with perfectly > > valid ones, at least on some mirrors. If the Apache copy were replaced, > then > > we wouldn't even be able to catch that it had happened. Given the high > > profile of Spark and the number of companies that run it, I think we > need to > > take extra care to make sure that can't happen, even if it is an > annoyance > > for the release managers. > > -- > Marcelo > > --------------------------------------------------------------------- > To unsubscribe e-mail: dev-unsubscr...@spark.apache.org > > -- Twitter: https://twitter.com/holdenkarau
