Does anybody know whether this is a hard blocker? If it is not, we should probably push 2.1.2 forward quickly and do the infrastructure improvement in parallel.
On Mon, Sep 18, 2017 at 7:49 PM, Holden Karau <hol...@pigscanfly.ca> wrote: > 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 >