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
lars hofhansl 2013-07-29, 21:45
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
> 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)
>