No and we could retire 2.2 now too but wouldn't hurt to keep it a bit longer in case we have to make a critical release even though it's EOL.
On Thu, Jan 24, 2019, 7:05 PM shane knapp <skn...@berkeley.edu wrote: > s/job/jobs > > these are for the spark-(master|branch-X)-docs builds, so right now i am > talking about removing 6 builds for the following branches: > > 1.6 > 2.0 > 2.1 > 2.3 > 2.4 > master > > in fact, do we even need ANY builds for 1.6, 2.0 and 2.1? > > On Thu, Jan 24, 2019 at 5:57 PM Sean Owen <sro...@gmail.com> wrote: > >> I think we can just remove this job. >> >> On Thu, Jan 24, 2019 at 6:44 PM shane knapp <skn...@berkeley.edu> wrote: >> > >> > On Sun, Jan 13, 2019 at 11:22 AM Felix Cheung < >> felixcheun...@hotmail.com> wrote: >> >> >> >> Eh, yeah, like the one with signing, I think doc build is mostly >> useful when a) right before we do a release or during the RC resets; b) >> someone makes a huge change to doc and want to check >> >> >> >> Not sure we need this nightly? >> >> >> > ohai! i found the thread! :) >> > >> > (see the other emails i sent today, i have currently disabled all of >> these branch-based nightly doc builds) >> > >> > anyways, my thoughts: >> > >> > we almost *certainly* do not need this to be run nightly... if at >> all. i am highly dubious of the relative usefulness of these builds. >> > >> > if someone is to make a massive amount of changes to the spark site, >> they can just manually create run the doc build (via 'do-release-docker.sh >> -n -s docs') and then check things out locally from the spark/docs/_site >> directory[1][2]. >> > >> > another option would be to ruby and jekyll installed on their dev >> machine (or a vm or whatever) and just run 'PRODUCTION=1 >> RELEASE_VERSION="$SPARK_VERSION" jekyll build' from the spark/docs subdir >> (with the new site appearing in spark/docs/_site)[2][3]. >> > >> > thoughts? >> > >> > shane >> > >> > [1] i'm not sure if that dir will be easily accessible outside of the >> spark-rm docker container, but i can probably check this out tomorrow. >> > [2] this will absolutely need to be documented somewhere (or >> somewheres). >> > [3] this is my preferred solution. >> > -- >> > Shane Knapp >> > UC Berkeley EECS Research / RISELab Staff Technical Lead >> > https://rise.cs.berkeley.edu >> > > > -- > Shane Knapp > UC Berkeley EECS Research / RISELab Staff Technical Lead > https://rise.cs.berkeley.edu >
