-> new subject I'll send my result of testing the RC separately On Sat, Dec 12, 2015 at 11:58 PM, Michael Armbrust <mich...@databricks.com> wrote: > > I'm only suggesting that we shouldn't delay testing of the actual bits, or > wait to iterate on another RC. Ideally docs should come out with the > actual release announcement (and I'll do everything in my power to make > this happen). The should also be updated regularly as small issues are > found. >
Certainly there is no reason to stop testing, like nobody would stop if any other issue were uncovered. You argued against a (non-binding) -1 on the grounds that doc problems aren't that important to the release, because they're published separately, possibly later. I don't think that can be the policy in general, and this is not a trivial problem. Still, docs are different, because not all project doc artifacts are released with code. I think it's a valid factor to consider when judging, is this tarball close enough for release? I'm guessing we all actually think that, so no problem. Previously people said to me that JIRAs like "Foo docs for x.y" are not necessarily intended to be done when x.y is released, because the site might not actually get updated for a week, and can filter in shortly after. That seemed unnecessarily seat-of-the-pants, and surely people don't mean it's *supposed* to work that way? While there is https://issues.apache.org/jira/browse/SPARK-11607 and about 4 unresolved doc issues for 1.6, I suspect they're actually done or not very important, so this is better than before. I don't think people do mean this. It has been in each case a practical argument, to not hold up the release further, and in all cases the release was late. > > But if it can/will be fixed quickly, what's the hurry? I get it, people >> want a releases sooner than later all else equal, but this is always true. >> It'd be nice to talk about what behaviors have led to being behind schedule >> and this perceived rush to finish now, since this same thing has happened >> in 1.5, 1.4. I'd rather at least collect some opinions on it than >> invalidate the question. >> > > I'm happy to debate concrete process suggestions on another thread. > Nothing new here. I dislike feeling that pressure to finish by a date is impacting judgments about whether it's close enough. But a fixed release cycle is good. All the activities leading to this RC have looked pretty good. (Score: still 28 issues targeted for 1.6, 11 bugs, no blockers). They just seem to be happening several weeks late, which is not nothing in a 13-week cycle, and yes it's enough to cause people to ask "when will this be ready?" The formula is supposed to be: 2 months development, 2 weeks QA, 2 weeks of finalizing from RCs, which seems right. 1.5 was about 2 weeks 'late' and in practice pushed this cycle back, which means this one isn't far off, just shifted. Closer. Concretely: to make releases reliably on time without a rush, RCs should start on time, which means burning down critical issues in QA from earlier, which means not overrunning the development window, and means scoping the right amount of work for ~2 months, and that requires earlier alignment on what to (not) do, and this leads back to paying attention to plans already made in JIRA. It's getting better and I think people find this a Good Idea, but could still be better. Whatever is to begin QA at the start of February: let's check in on the status at the start of each week in January or something? a baby step to making the idea of release schedule crop up earlier? (I digress because I imagine this side thread be a non-issue if we were here 3 weeks ago.)
