spark-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Patrick Wendell <>
Subject Re: [VOTE] Release Apache Spark 1.3.0 (RC3)
Date Fri, 06 Mar 2015 21:17:34 GMT

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 <> 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:  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 <> 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:
For additional commands, e-mail:

View raw message