hbase-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Lars George <lars.geo...@gmail.com>
Subject Re: Resolved JIRAs
Date Tue, 30 Jul 2013 05:21:18 GMT
+1 for #3 

On Jul 30, 2013, at 7:00, Nicolas Liochon <nkeywal@gmail.com> wrote:

> +1 for #3 as well
> Le 30 juil. 2013 06:44, "Ted Yu" <yuzhihong@gmail.com> a écrit :
> 
>> I would lean toward #3.
>> 
>> Cheers
>> 
>> On Mon, Jul 29, 2013 at 9:30 PM, lars hofhansl <larsh@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.soz@gmail.com>
>>> To: "dev@hbase.apache.org" <dev@hbase.apache.org>; lars hofhansl <
>>> larsh@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 <larsh@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 <yuzhihong@gmail.com>
>>>> To: dev@hbase.apache.org
>>>> Cc: lars hofhansl <larsh@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 <apurtell@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 <larsh@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 <apurtell@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.george@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)
>> 

Mime
View raw message