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) >> > >
