I would lean toward #3. Cheers
On Mon, Jul 29, 2013 at 9:30 PM, lars hofhansl <la...@apache.org> wrote: > As long as we all agree. :) > > We have three options: > > 1. separate jiras for each version > 2. last release closes jira > 3. first release closes jira, separate jiras needed for further changes > > It should also be easy to determine which jiras need to be close and be > able to do that in bulk. That is easy in #1 and #3, but hard for #2. > #1 and #2 are easier to understand. > #3 can be confusing. > #1 is cumbersome. > > My vote would remain with #3. > > -- Lars > > > > ________________________________ > From: Enis Söztutar <enis....@gmail.com> > To: "dev@hbase.apache.org" <dev@hbase.apache.org>; lars hofhansl < > la...@apache.org> > Sent: Monday, July 29, 2013 7:01 PM > Subject: Re: Resolved JIRAs > > > > I think it makes sense to group fix versions in the same jira as long as > there is no significant time delay between patches getting in. First > release closing the issue also makes sense, since closing is basically > marking the issue as complete. If addendums are needed, we can do another > jira. > > > > On Mon, Jul 29, 2013 at 2:45 PM, lars hofhansl <la...@apache.org> wrote: > > Yeah, but that would be a lot of extra jiras to file. > >I think we can co-fix issues across multiple branches exactly until one > of them is released. > > > >We should not add new patches over long time spans to the same jira > anyway. > > > > > > > >-- Lars > > > > > > > >----- Original Message ----- > > > >From: Ted Yu <yuzhih...@gmail.com> > >To: dev@hbase.apache.org > >Cc: lars hofhansl <la...@apache.org> > >Sent: Monday, July 29, 2013 2:39 PM > >Subject: Re: Resolved JIRAs > > > >bq. another way to do this is not have issues that target multiple > >branches/releases. > > > >+1 > > > >On Mon, Jul 29, 2013 at 2:34 PM, Andrew Purtell <apurt...@apache.org> > wrote: > > > >> > The argument could also be made that *any* release should lead to > closing > >> the issue > >> > >> For issues that have multiple commit/target versions, we can close it > after > >> the first release goes out but then we can't change it's state if > there's > >> an issue with another branch/release, maybe as simple as making sure it > got > >> committed there or (re)testing. That could be fine, I have no strong > >> opinion. > >> > >> Or another way to do this is not have issues that target multiple > >> branches/releases. > >> > >> > >> On Mon, Jul 29, 2013 at 2:22 PM, lars hofhansl <la...@apache.org> > wrote: > >> > >> > Hmm... That would would be difficult to track in bulk, though. > >> > It's true that I have closed all 0.94.x issues when 0.94.x is > released. > >> > That has been very helpful to identify jiras that folks mislabel later > >> > (which happens very frequently). > >> > > >> > The argument could also be made that *any* release should lead to > closing > >> > the issue (as long as it has a fix for said version, of course).At > that > >> > point the code is out in the wild and is used, any change now should > >> > require a new jira. > >> > > >> > -- Lars > >> > > >> > > >> > > >> > ----- Original Message ----- > >> > From: Andrew Purtell <apurt...@apache.org> > >> > To: dev@hbase.apache.org > >> > Cc: > >> > Sent: Monday, July 29, 2013 12:19 PM > >> > Subject: Re: Resolved JIRAs > >> > > >> > On Mon, Jul 29, 2013 at 11:06 AM, Lars George <lars.geo...@gmail.com> > >> > wrote: > >> > > >> > > That is exactly my point, ie the former case. If I commit to all > major > >> > > branches within a day as is common, but the branches release at > various > >> > > times, who is going to close the issue? The release manager who > >> releases > >> > > first? > >> > > >> > > >> > IMHO: > >> > > >> > The commiter should set the state to 'Resolved' after the change is > >> applied > >> > to all desired target branches. > >> > > >> > The RM for the _last_ affected release should set the state to > 'Closed', > >> > essentially garbage collecting when refcount goes to 0. > >> > > >> > -- > >> > Best regards, > >> > > >> > - Andy > >> > > >> > Problems worthy of attack prove their worth by hitting back. - Piet > Hein > >> > (via Tom White) > >> > > >> > > >> > >> > >> -- > >> Best regards, > >> > >> - Andy > >> > >> Problems worthy of attack prove their worth by hitting back. - Piet Hein > >> (via Tom White) > >> > > > > >
