@Ryan yes you're speaking about the non-version-specific docs, and I agree there seems to be no particular reason not to update those continuously. (I also don't know how that relates to the doc release policy.) But it's not quite the issue here.
@Matei I agree with you, except you seem to say it's completely fine, and not fine, to update the website docs. If you mean "technically permissible" and then "not a good idea", I agree. The release policy is probably construed to pertain to signed and delivered source/doc artifacts. It's a moot point for 2.2. If we're more importantly in agreement that we ought to get docs for release X done with release X in principle, that's good. On Thu, Jun 8, 2017 at 11:42 PM Matei Zaharia <matei.zaha...@gmail.com> wrote: > I agree that it seems completely fine to update the web version of the > docs after a release. What would not be fine is updating the downloadable > package for it without another vote (and another release number). When > people voted on a release, they voted that we should put up that package as > "spark-2.1.0.tgz" or whatever, which is not changing here. > > At the same time though, even though docs on the website *can* be updated > after, it might not be smart to release something until the docs *are* > fully in sync with the new features -- otherwise users might get confused. > > Matei > > On Jun 8, 2017, at 3:25 PM, Ryan Blue <rb...@netflix.com.INVALID > <rb...@netflix.com.invalid>> wrote: > > I've never thought that docs are strictly part of a release and can't be > updated outside of one. Javadoc jars are included in releases with jars, > but that's more because they are produced by the build and are tied to the > source code. There is plenty of other documentation that isn't normally > included in a release, like the project's web pages and wiki content. I > think the expectation is for that to be continuously updated. So my > interpretation is that the release artifacts in the document you're quoting > from are the source code and convenience binaries. There's definitely room > for interpretation here, but I don't think it would be a problem as long as > we do something reasonable. > > On Tue, Jun 6, 2017 at 2:15 AM, Sean Owen <so...@cloudera.com> wrote: > >> That's good, but, I think we should agree on whether release docs are >> part of a release. It's important to reasoning about releases. >> >> To be clear, you're suggesting that, say, right now you are OK with >> updating this page with a few more paragraphs? >> http://spark.apache.org/docs/2.1.0/streaming-programming-guide.html >> Even though those paragraphs can't be in the released 2.1.0 doc source? >> >> First, what is everyone's understanding of the answer? >> >> The only official guidance I can find is >> http://www.apache.org/legal/release-policy.html#distribute-other-artifacts , >> which suggests that docs need to be released similarly, with signatures. >> Not quite the same question, but strongly implies they're treated like any >> other source that is released with a vote. >> >> ------ >> >> WHAT ARE THE REQUIREMENTS TO DISTRIBUTE OTHER ARTIFACTS IN ADDITION TO >> THE SOURCE PACKAGE? >> <http://www.apache.org/legal/release-policy.html#distribute-other-artifacts> >> >> ASF releases typically contain additional material together with the >> source package. This material may include documentation concerning the >> release but must contain LICENSE and NOTICE files. As mentioned above, >> these artifacts must be signed by a committer with a detached signature if >> they are to be placed in the project's distribution directory. >> >> Again, these artifacts may be distributed only if they contain LICENSE >> and NOTICE files. For example, the Java artifact format is based on a >> compressed directory structure and those projects wishing to distribute >> jars must place LICENSE and NOTICE files in the META-INF directory within >> the jar. >> >> Nothing in this section is meant to supersede the requirements defined >> here <http://www.apache.org/legal/release-policy.html#what> and here >> <http://www.apache.org/legal/release-policy.html#what-must-every-release-contain> >> that all releases be primarily based on a signed source package. >> >> On Tue, Jun 6, 2017 at 9:50 AM Nick Pentreath <nick.pentre...@gmail.com> >> wrote: >> >>> The website updates for ML QA (SPARK-20507) are not *actually* critical >>> as the project website certainly can be updated separately from the source >>> code guide and is not part of the release to be voted on. In future that >>> particular work item for the QA process could be marked down in priority, >>> and is definitely not a release blocker. >>> >>> In any event I just resolved SPARK-20507, as I don't believe any website >>> updates are required for this release anyway. That fully resolves the ML QA >>> umbrella (SPARK-20499). >>> >>>> >>>> > > > -- > Ryan Blue > Software Engineer > Netflix > > >
