I appreciate targets having the strong meaning you suggest, as its useful to get a sense of what will realistically be included in a release.
Would it make sense (speaking as a relative outsider here) that we would not enter into the RC phase of a release until all JIRA targeting that release were complete? If a JIRA targeting a release is blocking entry to the RC phase, and its determined that the JIRA should not hold up the release, than it should get re-targeted to the next release. -Chris On 6/17/15, 3:55 PM, "Patrick Wendell" <pwend...@gmail.com> wrote: >Hey Sean, > >Thanks for bringing this up - I went through and fixed about 10 of >them. Unfortunately there isn't a hard and fast way to resolve them. I >found all of the following: > >- Features that missed the release and needed to be retargeted to 1.5. >- Bugs that missed the release and needed to be retargeted to 1.4.1. >- Issues that were not properly targeted (e.g. someone randomly set >the target version) and should probably be untargeted. > >I'd like to encourage others to do this, especially the more active >developers on different components (Streaming, ML, etc). > >One other question is what the semantics of target version are, which >I don't think we've defined clearly. Is it the target of the person >contributing the feature? Or in some sense the target of the >committership? My preference would be that targeting a JIRA has some >strong semantics - i.e. it means the commiter targeting has mentally >allocated time to review a patch for that feature in the timeline of >that release. I.e. prefer to have fewer targeted JIRA's for a release, >and also expect to get most of the targeted features merged into a >release. In the past I think targeting has meant different things to >different people. > >- Patrick > >On Tue, Jun 16, 2015 at 8:09 AM, Josh Rosen <rosenvi...@gmail.com> wrote: >> Whatever you do, DO NOT use the built-in JIRA 'releases' feature to >>migrate >> issues from 1.4.0 to another version: the JIRA feature will have the >> side-effect of automatically changing the target versions for issues >>that >> have been closed, which is going to be really confusing. I've made this >> mistake once myself and it was a bit of a hassle to clean up. >> >> On Tue, Jun 16, 2015 at 5:24 AM, Sean Owen <so...@cloudera.com> wrote: >>> >>> Question: what would happen if I cleared Target Version for everything >>> still marked Target Version = 1.4.0? There are 76 right now, and >>> clearly that's not correct. >>> >>> 56 were opened by committers, including issues like "Do X for 1.4". >>> I'd like to understand whether these are resolved but just weren't >>> closed, or else why so many issues are being filed as a todo and not >>> resolved? Slipping things here or there is OK, but these weren't even >>> slipped, just forgotten. >>> >>> On Sat, May 30, 2015 at 3:55 PM, Sean Owen <so...@cloudera.com> wrote: >>> > In an ideal world, Target Version really is what's going to go in as >>> > far as anyone knows and when new stuff comes up, we all have to >>>figure >>> > out what gets dropped to fit by the release date. Boring, standard >>> > software project management practice. I don't know how realistic that >>> > is, but, I'm wondering how people feel about this, who have filed >>> > these JIRAs? >>> > >>> > Concretely, should non-Critical issues for 1.4.0 be un-Targeted? >>> > should they all be un-Targeted after the release? >>> >>> --------------------------------------------------------------------- >>> 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 >
smime.p7s
Description: S/MIME cryptographic signature
