+1 for #3 On Jul 30, 2013, at 7:00, Nicolas Liochon <nkey...@gmail.com> wrote:
> +1 for #3 as well > Le 30 juil. 2013 06:44, "Ted Yu" <yuzhih...@gmail.com> a écrit : > >> 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) >>
