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 <[email protected]> To: [email protected] Cc: lars hofhansl <[email protected]> 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 <[email protected]> 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 <[email protected]> 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 <[email protected]> > > To: [email protected] > > Cc: > > Sent: Monday, July 29, 2013 12:19 PM > > Subject: Re: Resolved JIRAs > > > > On Mon, Jul 29, 2013 at 11:06 AM, Lars George <[email protected]> > > 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) >
