So is this open for vote then or are we waiting on other things?
Tom
On Thursday, June 25, 2015 10:32 AM, Andrew Ash <and...@andrewash.com>
wrote:
I would guess that many tickets targeted at 1.4.1 were set that way during the
tail end of the 1.4.0 voting process as people realized they wouldn't make the
.0 release in time. In that case, they were likely aiming for a 1.4.x release,
not necessarily 1.4.1 specifically. Maybe creating a "1.4.x" target in Jira in
addition to 1.4.0, 1.4.1, 1.4.2, etc would make it more clear that these
tickets are targeted at "some 1.4 update release" rather than specifically "the
1.4.1 update".
On Thu, Jun 25, 2015 at 5:38 AM, Sean Owen <so...@cloudera.com> wrote:
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
