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

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


+
Lars George 2013-07-29, 13:06
+
Nicolas Liochon 2013-07-29, 13:18
+
Lars George 2013-07-29, 13:46
+
Ted Yu 2013-07-29, 13:57
+
Nicolas Liochon 2013-07-29, 16:38
+
lars hofhansl 2013-07-29, 17:23
+
Lars George 2013-07-29, 18:06
+
Andrew Purtell 2013-07-29, 19:19
+
Lars George 2013-07-29, 20:41
+
Andrew Purtell 2013-07-29, 20:43
+
Stack 2013-07-29, 21:06
+
Uma Maheswara Rao G 2013-07-29, 20:54
+
lars hofhansl 2013-07-29, 21:22
+
Andrew Purtell 2013-07-29, 21:34
+
Ted Yu 2013-07-29, 21:39
+
lars hofhansl 2013-07-29, 21:45
Copy link to this message
-
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
> > 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)
> >
>
>
+
lars hofhansl 2013-07-30, 04:30
+
Ted Yu 2013-07-30, 04:43
+
Nicolas Liochon 2013-07-30, 05:00
+
Lars George 2013-07-30, 05:21
+
Jesse Yates 2013-07-30, 06:03
+
Stack 2013-08-01, 15:31
+
Lars George 2013-07-29, 13:45