All tasks on the R QA umbrella are completed SPARK-20512 We can close this.
_____________________________ From: Sean Owen <so...@cloudera.com<mailto:so...@cloudera.com>> Sent: Tuesday, June 6, 2017 1:16 AM Subject: Re: [VOTE] Apache Spark 2.2.0 (RC4) To: Michael Armbrust <mich...@databricks.com<mailto:mich...@databricks.com>> Cc: <dev@spark.apache.org<mailto:dev@spark.apache.org>> On Tue, Jun 6, 2017 at 1:06 AM Michael Armbrust <mich...@databricks.com<mailto:mich...@databricks.com>> wrote: 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. They are valuable, I only suggest it's better to note explicitly when there are blockers or must-do tasks that will fail the RC. It makes a big difference to whether one would like to +1. I meant more than just calling them something different. An early RC could be voted as a released 'preview' artifact, at the start of the notional QA period, with a lower bar to passing, and releasable with known issues. This encourages more testing. It also resolves the controversy about whether it's OK to include an RC in a product (separate thread). 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. They're part of the source release too, as markdown, and should be voted on. I've never understood otherwise. Have we actually released docs and then later changed them, so that they don't match the release? I don't recall that, but I do recall updating the non-version-specific website. Aside from the oddity of having docs generated from x.y source not match docs published for x.y, you want the same protections for doc source that the project distributes as anything else. It's not just correctness, but liability. The hypothetical is always that someone included copyrighted text or something without permission and now the project can't rely on the argument that it made a good-faith effort to review what it released on the site. Someone becomes personally liable. These are pretty technical reasons though. More practically, what's the hurry to release if docs aren't done (_if_ they're not done)? It's being presented as normal practice, but seems quite exceptional. 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. QA on RCs is great (see above). The problem is, I can't distinguish between a JIRA that means "we must test in general", which sounds like something you too would ignore, and one that means "there is specific functionality we have to check before a release that we haven't looked at yet", which is a committer waving a flag that they implicitly do not want a release until resolved. I wouldn't +1 a release that had a Blocker software defect one of us reported. I know I'm harping on this, but this is the one mechanism we do use consistently (Blocker JIRAs) to clearly communicate about issues vital to a go / no-go release decision, and I think this interferes. The rest of JIRA noise doesn't matter much. You can see we're already resorting to secondary communications as a result ("anyone have any issues that need to be fixed before I cut another RC?" emails) because this is kind of ignored, and think we're swapping out a decent mechanism for worse one. I suspect, as you do, that there's no to-do here in which case they should be resolved and we're still on track for release. I'd wait on +1 until then.
