hbase-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Ted Yu <yuzhih...@gmail.com>
Subject Re: Resolved JIRAs
Date Tue, 30 Jul 2013 04:43:58 GMT
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
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message