Home | About | Sematext search-lucene.com search-hadoop.com
NEW: Monitor These Apps!
elasticsearch, apache solr, apache hbase, hadoop, redis, casssandra, amazon cloudwatch, mysql, memcached, apache kafka, apache zookeeper, apache storm, ubuntu, centOS, red hat, debian, puppet labs, java, senseiDB
 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
+
Enis Söztutar 2013-07-30, 02:01
+
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
Copy link to this message
-
Re: Resolved JIRAs
+1 for #3.

And well articulated Lars (H).
-------------------
Jesse Yates
@jesse_yates
jyates.github.com
On Mon, Jul 29, 2013 at 10:21 PM, Lars George <[EMAIL PROTECTED]> wrote:

> +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]
+
Stack 2013-08-01, 15:31
+
Lars George 2013-07-29, 13:45
NEW: Monitor These Apps!
elasticsearch, apache solr, apache hbase, hadoop, redis, casssandra, amazon cloudwatch, mysql, memcached, apache kafka, apache zookeeper, apache storm, ubuntu, centOS, red hat, debian, puppet labs, java, senseiDB