On Tue, Jun 6, 2017 at 1:06 AM Michael Armbrust <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.
