To add to what Patrick said, the only reason that those JIRAs are marked as Blockers (at least I can say for myself) is so that they are at the top of the JIRA list signifying that these are more *immediate* issues than all the Critical issues. To make it less confusing for the community voting, we can definitely add a filter that ignores Documentation issues from the JIRA list.
On Fri, Mar 6, 2015 at 1:17 PM, Patrick Wendell <pwend...@gmail.com> wrote: > 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 > >
