I also like using Target Version meaningfully. It might be a little much to require no Target Version = X before starting an RC. I do think it's reasonable to not start the RC with Blockers open.
And here we started the RC with almost 100 TODOs for 1.4.0, most of which did not get done. Not the end of the world, but, clearly some other decisions were made in the past based on the notion that most of those would get done. The 'targeting' is too optimistic. Given fixed time, adding more TODOs generally means other stuff has to be taken out for the release. If not, then it happens de facto anyway, which is worse than managing it on purpose. Anyway, thanks all for the attention to some cleanup. I'll wait a short while and then fix up the rest of them as intelligently as I can. Maybe I can push on this a little the next time we have a release cycle to see how we're doing with use of Target Version. On Wed, Jun 17, 2015 at 10:03 PM, Heller, Chris <chel...@akamai.com> wrote: > 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 >> --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscr...@spark.apache.org For additional commands, e-mail: dev-h...@spark.apache.org
