tomorrow i will continue the purge. :) On Thu, Jan 24, 2019 at 6:13 PM Sean Owen <sro...@gmail.com> wrote:
> 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 >> > -- Shane Knapp UC Berkeley EECS Research / RISELab Staff Technical Lead https://rise.cs.berkeley.edu
