That makes sense to me -- there's an urgent fix to get out. I missed that part. Not that it really matters but was that expressed elsewhere?
I know we tend to start the RC process even when a few more changes are still in progress, to get a first wave or two of testing done early, knowing that the RC won't be the final one. It makes sense for some issues for X to be open when an RC is cut, if they are actually truly intended for X. 44 seems like a lot, and I don't think it's good practice just because that's how it's happened before. It looks like half of them weren't actually important for 1.4.x as we're now down to 21. I don't disagree with the idea that only "most" of the issues targeted for version X will be in version X; the target expresses a "stretch goal". Given the fast pace of change that's probably the only practical view. I think we're just missing a step then: before RC of X, ask people to review and update the target of JIRAs for X? In this case, it was a good point to untarget stuff from 1.4.x entirely; I suspect everything else should then be targeted at 1.4.2 by default with the exception of a handful that people really do intend to work in for 1.4.1 before its final release. I know it sounds like pencil-pushing, but it's a cheap way to bring some additional focus to release planning. RC time has felt like a last-call to *begin* changes ad-hoc when it would go faster if it were more intentional and constrained. Meaning faster RCs, meaning getting back to a 3-month release cycle or less, and meaning less rush to push stuff into a .0 release and less frequent need for a maintenance .1 version. So what happens if all 1.4.1-targeted JIRAs are targeted to 1.4.2? would that miss something that is definitely being worked on for 1.4.1? On Wed, Jun 24, 2015 at 6:56 PM, Patrick Wendell <pwend...@gmail.com> wrote: > Hey Sean, > > This is being shipped now because there is a severe bug in 1.4.0 that > can cause data corruption for Parquet users. > > There are no blockers targeted for 1.4.1 - so I don't see that JIRA is > inconsistent with shipping a release now. The goal of having every > single targeted JIRA cleared by the time we start voting, I don't > think there is broad consensus and cultural adoption of that principle > yet. So I do not take it as a signal this release is premature (the > story has been the same for every previous release we've ever done). > > The fact that we hit 90/124 of issues targeted at this release means > we are targeting such that we get around 70% of issues merged. That > actually doesn't seem so bad to me since there is some uncertainty in > the process. B > > - Patrick > > On Wed, Jun 24, 2015 at 1:54 AM, Sean Owen <so...@cloudera.com> wrote: >> There are 44 issues still targeted for 1.4.1. None are Blockers; 12 >> are Critical. ~80% were opened and/or set by committers. Compare with >> 90 issues resolved for 1.4.1. >> >> I'm concerned that committers are targeting lots more for a release >> even in the short term than realistically can go in. On its face, it >> suggests that an RC is premature. Why is 1.4.1 being put forth for >> release now? It seems like people are saying they want a fair bit more >> time to work on 1.4.1. >> >> I suspect that in fact people would rather untarget / slip (again) >> these JIRAs, but it calls into question again how the targeting is >> consistently off by this much. >> >> What unresolved JIRAs targeted for 1.4.1 are *really* still open for >> 1.4.1? like, what would go badly if all 32 non-Critical JIRAs were >> untargeted now? is the reality that there are a handful of items to >> get in before the final release, and those are hopefully the ~12 >> critical ones? How about some review of that before we ask people to >> seriously test these bits? >> >> On Wed, Jun 24, 2015 at 8:37 AM, Patrick Wendell <pwend...@gmail.com> wrote: >>> Please vote on releasing the following candidate as Apache Spark version >>> 1.4.1! >>> >>> This release fixes a handful of known issues in Spark 1.4.0, listed here: >>> http://s.apache.org/spark-1.4.1 >>> >>> The tag to be voted on is v1.4.1-rc1 (commit 60e08e5): >>> https://git-wip-us.apache.org/repos/asf?p=spark.git;a=commit;h= >>> 60e08e50751fe3929156de956d62faea79f5b801 >>> >>> The release files, including signatures, digests, etc. can be found at: >>> http://people.apache.org/~pwendell/spark-releases/spark-1.4.1-rc1-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: >>> [published as version: 1.4.1] >>> https://repository.apache.org/content/repositories/orgapachespark-1118/ >>> [published as version: 1.4.1-rc1] >>> https://repository.apache.org/content/repositories/orgapachespark-1119/ >>> >>> The documentation corresponding to this release can be found at: >>> http://people.apache.org/~pwendell/spark-releases/spark-1.4.1-rc1-docs/ >>> >>> Please vote on releasing this package as Apache Spark 1.4.1! >>> >>> The vote is open until Saturday, June 27, at 06:32 UTC and passes >>> if a majority of at least 3 +1 PMC votes are cast. >>> >>> [ ] +1 Release this package as Apache Spark 1.4.1 >>> [ ] -1 Do not release this package because ... >>> >>> To learn more about Apache Spark, please see >>> http://spark.apache.org/ >>> >>> --------------------------------------------------------------------- >>> To unsubscribe, e-mail: dev-unsubscr...@spark.apache.org >>> For additional commands, e-mail: dev-h...@spark.apache.org >>> --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscr...@spark.apache.org For additional commands, e-mail: dev-h...@spark.apache.org
