Home | About | Sematext search-lucene.com search-hadoop.com
 Search Hadoop and all its subprojects:

Switch to Threaded View
HBase >> mail # dev >> Resolved JIRAs


Copy link to this message
-
Re: Resolved JIRAs
+1 for #3

On Jul 30, 2013, at 7:00, Nicolas Liochon <[EMAIL PROTECTED]> wrote:

> +1 for #3 as well
> Le 30 juil. 2013 06:44, "Ted Yu" <[EMAIL PROTECTED]> a écrit :
>
>> I would lean toward #3.
>>
>> Cheers
>>
>> On Mon, Jul 29, 2013 at 9:30 PM, lars hofhansl <[EMAIL PROTECTED]> 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 <[EMAIL PROTECTED]>
>>> To: "[EMAIL PROTECTED]" <[EMAIL PROTECTED]>; lars hofhansl <
>>> [EMAIL PROTECTED]>
>>> 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 <[EMAIL PROTECTED]> 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 <[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