Sean, The docs are distributed and consumed in a fundamentally different way than Spark code itself. So we've always considered the "deadline" for doc changes to be when the release is finally posted.
If there are small inconsistencies with the docs present in the source code for that release tag, IMO that doesn't matter much since we don't even distribute the docs with Spark's binary releases and virtually no one builds and hosts the docs on their own (that I am aware of, at least). Perhaps we can recommend if people want to build the doc sources that they should always grab the head of the most recent release branch, to set expectations accordingly. In the past we haven't considered it worth holding up the release process for the purpose of the docs. It just doesn't make sense since they are consumed "as a service". If we decide to change this convention, it would mean shipping our releases later, since we could't pipeline the doc finalization with voting. - Patrick On Fri, Mar 6, 2015 at 11:02 AM, Sean Owen <so...@cloudera.com> wrote: > Given the title and tagging, it sounds like there could be some > must-have doc changes to go with what is being released as 1.3. It can > be finished later, and published later, but then the docs source > shipped with the release doesn't match the site, and until then, 1.3 > is released without some "must-have" docs for 1.3 on the site. > > The real question to me is: are there any further, absolutely > essential doc changes that need to accompany 1.3 or not? > > If not, just resolve these. If there are, then it seems like the > release has to block on them. If there are some docs that should have > gone in for 1.3, but didn't, but aren't essential, well I suppose it > bears thinking about how to not slip as much work, but it doesn't > block. > > I think Documentation issues certainly can be a blocker and shouldn't > be specially ignored. > > > BTW the UISeleniumSuite issue is a real failure, but I do not think it > is serious: http://issues.apache.org/jira/browse/SPARK-6205 It isn't > a regression from 1.2.x, but only affects tests, and only affects a > subset of build profiles. > > > > > On Fri, Mar 6, 2015 at 6:43 PM, Patrick Wendell <pwend...@gmail.com> wrote: >> Hey Sean, >> >>> SPARK-5310 Update SQL programming guide for 1.3 >>> SPARK-5183 Document data source API >>> SPARK-6128 Update Spark Streaming Guide for Spark 1.3 >> >> For these, the issue is that they are documentation JIRA's, which >> don't need to be timed exactly with the release vote, since we can >> update the documentation on the website whenever we want. In the past >> I've just mentally filtered these out when considering RC's. I see a >> few options here: >> >> 1. We downgrade such issues away from Blocker (more clear, but we risk >> loosing them in the fray if they really are things we want to have >> before the release is posted). >> 2. We provide a filter to the community that excludes 'Documentation' >> issues and shows all other blockers for 1.3. We can put this on the >> wiki, for instance. >> >> Which do you prefer? >> >> - Patrick --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscr...@spark.apache.org For additional commands, e-mail: dev-h...@spark.apache.org
