Apologies for messing up the https urls. My mistake. I'll try to get it right next time.
Regarding the readiness of this and previous RCs. I did cut RC1 & RC2 knowing that they were unlikely to pass. That said, I still think these early RCs are valuable. I know several users that wanted to test new features in 2.2 that have used them. Now, if we would prefer to call them preview or RC0 or something I'd be okay with that as well. Regarding doc updates, I don't think it is a requirement that they be voted on as part of the release. Even if they are something version specific. I think we have regularly updated the website with documentation that was merged after the release. I personally don't think the QA umbrella JIRAs are particularly effective, but I also wouldn't ban their use if others think they are. However, I do think that real QA needs an RC to test, so I think it is fine that there is still outstanding QA to be done when an RC is cut. For example, I plan to run a bunch of streaming workloads on RC4 and will vote accordingly. TLDR; Based on what I have heard from everyone so far, there are currently no know issues that should fail the vote here. We should begin testing RC4. Thanks to everyone for your help! On Mon, Jun 5, 2017 at 1:20 PM, Sean Owen <so...@cloudera.com> wrote: > (I apologize for going on about this, but I've asked ~4 times: could you > make the URLs here in the form email HTTPS URLs? It sounds minor, but we're > asking people to verify the integrity of software and hashes, and this is > the one case where it is actually important.) > > The "2.2" JIRAs don't look like updates to the non-version-specific web > pages. If they affect release docs (i.e. under spark.apache.org/docs/), > or the code, those QA/doc updates have to happen before a release. Right? I > feel like this is self-evident but this comes up every minor release, that > some testing or doc changes for a release can happen after the code and > docs for the release are finalized. They obviously can't. > > I know, I get it. I think the reality is that the reporters don't believe > there is something must-do for the 2.2.0 release, or else they'd have > spoken up. In that case, these should be closed already as they're > semantically "Blockers" and we shouldn't make an RC that can't pass. > > ... or should we? Actually, to me the idea of an "RC0" release as a > preview, and RCs that are known to fail for testing purposes seem OK. But > if that's the purpose here, let's say it. > > If the "QA" JIRAs just represent that 'we will test things, in general', > then I think they're superfluous at best. These aren't used consistently, > and their intent isn't actionable (i.e. it sounds like no particular > testing resolves the JIRA). They signal something that doesn't seem to > match the intent. > > Can we close the QA JIRAs -- and are there any actual must-have docs not > already in the 2.2 branch? > > On Mon, Jun 5, 2017 at 8:52 PM Michael Armbrust <mich...@databricks.com> > wrote: > >> I commented on that JIRA, I don't think that should block the release. >> We can support both options long term if this vote passes. Looks like the >> remaining JIRAs are doc/website updates that can happen after the vote or >> QA that should be done on this RC. I think we are ready to start testing >> this release seriously! >> >> On Mon, Jun 5, 2017 at 12:40 PM, Sean Owen <so...@cloudera.com> wrote: >> >>> Xiao opened a blocker on 2.2.0 this morning: >>> >>> SPARK-20980 Rename the option `wholeFile` to `multiLine` for JSON and CSV >>> >>> I don't see that this should block? >>> >>> We still have 7 Critical issues: >>> >>> SPARK-20520 R streaming tests failed on Windows >>> SPARK-20512 SparkR 2.2 QA: Programming guide, migration guide, vignettes >>> updates >>> SPARK-20499 Spark MLlib, GraphX 2.2 QA umbrella >>> SPARK-20508 Spark R 2.2 QA umbrella >>> SPARK-20513 Update SparkR website for 2.2 >>> SPARK-20510 SparkR 2.2 QA: Update user guide for new features & APIs >>> SPARK-20507 Update MLlib, GraphX websites for 2.2 >>> >>> I'm going to assume that the R test issue isn't actually that big a >>> deal, and that the 2.2 items are done. Anything that really is for 2.2 >>> needs to block the release; Joseph what's the status on those? >>> >>> On Mon, Jun 5, 2017 at 8:15 PM Michael Armbrust <mich...@databricks.com> >>> wrote: >>> >>>> Please vote on releasing the following candidate as Apache Spark >>>> version 2.2.0. The vote is open until Thurs, June 8th, 2017 at 12:00 >>>> PST and passes if a majority of at least 3 +1 PMC votes are cast. >>>> >>>> [ ] +1 Release this package as Apache Spark 2.2.0 >>>> [ ] -1 Do not release this package because ... >>>> >>>> >>>> To learn more about Apache Spark, please see http://spark.apache.org/ >>>> >>>> The tag to be voted on is v2.2.0-rc4 >>>> <https://github.com/apache/spark/tree/v2.2.0-rc4> (377cfa8ac7ff7a8 >>>> a6a6d273182e18ea7dc25ce7e) >>>> >>>> List of JIRA tickets resolved can be found with this filter >>>> <https://issues.apache.org/jira/browse/SPARK-20134?jql=project%20%3D%20SPARK%20AND%20fixVersion%20%3D%202.2.0> >>>> . >>>> >>>> The release files, including signatures, digests, etc. can be found at: >>>> http://home.apache.org/~pwendell/spark-releases/spark-2.2.0-rc4-bin/ >>>> >>>> Release artifacts are signed with the following key: >>>> https://people.apache.org/keys/committer/pwendell.asc >>>> >>>> The staging repository for this release can be found at: >>>> https://repository.apache.org/content/repositories/orgapachespark-1241/ >>>> >>>> The documentation corresponding to this release can be found at: >>>> http://people.apache.org/~pwendell/spark-releases/spark-2.2.0-rc4-docs/ >>>> >>>> >>>> *FAQ* >>>> >>>> *How can I help test this release?* >>>> >>>> If you are a Spark user, you can help us test this release by taking an >>>> existing Spark workload and running on this release candidate, then >>>> reporting any regressions. >>>> >>>> *What should happen to JIRA tickets still targeting 2.2.0?* >>>> >>>> Committers should look at those and triage. Extremely important bug >>>> fixes, documentation, and API tweaks that impact compatibility should be >>>> worked on immediately. Everything else please retarget to 2.3.0 or 2.2.1. >>>> >>>> *But my bug isn't fixed!??!* >>>> >>>> In order to make timely releases, we will typically not hold the >>>> release unless the bug in question is a regression from 2.1.1. >>>> >>> >>
