accumulo-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Eric Newton <>
Subject Re: On ticket management
Date Thu, 03 May 2012 02:55:01 GMT
For example,

The leapfrogging through the indices could be made better if we initially
search on "paris" and then "spring" vs "in" or "the" when searching for
documents containing "paris" and "in" and "the" and "spring".  We already
know the relative counts, we just need smarter code.

The client API is sort of brittle and not very helpful when return results
exceed client buffer capability.

The code could use some additional documentation, such as how to use it
with a different corpus.


On Wed, May 2, 2012 at 9:51 PM, Josh Elser <> wrote:

> If you're interested from an application development standpoint, you could
> go bug-hunting, finding performance bottlenecks, or add some features to
> the wikipedia example.
> I'm rather sure there are optimizations to be had in that code.
> On 05/02/2012 04:53 PM, wrote:
>> Most of what I'm using involves map/reduce functions to ingest bulk data,
>> batch writers for streaming data ingest, and batch scanners (particularly
>> document partition scanners) to get it back out.  So I guess those are my
>> areas of interest.
>> -----Original Message-----
>> From: Keith Turner []
>> Sent: Wednesday, May 02, 2012 16:50
>> To:
>> Subject: Re: On ticket management
>> Is there anything in particular that you are interested in?
>> On Wed, May 2, 2012 at 5:36 PM,<>  wrote:
>>> There's probably many folks like myself that would like to contribute
>>> but have no idea where/how to get started.  Any suggestions?
>>> -----Original Message-----
>>> From: Eric Newton []
>>> Sent: Wednesday, May 02, 2012 10:34
>>> To:
>>> Subject: Re: On ticket management
>>> Tickets that remain unassigned don't seem to get any attention.
>>> I've been trying to close as many "easy" tickets as I can over the
>>> last few days... and there's this giant pile of tickets that are
>>> unassigned that I've not even started to look at.
>>> Unless we are rigorous about going through the unassigned tickets, I
>>> prefer to keep them assigned to someone.
>>> -Eric
>>> On Wed, May 2, 2012 at 9:31 AM, John Vines<>
>>> wrote:
>>>  So early on we took the stance that different committers owned
>>>> different realms of the project. This makes sense, because we want to
>>>> make sure that outside contributors don't have their patches ignored.
>>>> However, this also means that all tickets under realm X will be
>>> assigned to that person.
>>>> I am not a fan of this approach, for a few different reasons- 1.
>>>> Committers get pidgeon-holed into very specific realms of the project
>>>> 2. Committers can find themselves stuck with tickets that they are
>>>> not
>>>> that aware of and/or don't understand 3. Outsiders can be hesitant to
>>>> begin contribution because with a ticket assigned they could think
>>>> that they are working on it 4. At least for me, I would like to use
>>>> assigned tickets to keep track of what I have on *MY* plate. That is,
>>>> the things that I am working on and/or want and plan to work on next.
>>>> I'm wondering what everyone's thoughts would be on making the default
>>>> behavior for new tickets be unassigned (I imagine this is possible in
>>>> JIRA) and the method for ticket assignment.  We can still divide up
>>>> the realms for the committers for ensuring validity of the tickets
>>>> and
>>>> for handling patches though.  This would also mean purging all
>>>> current
>>>> ticket assignments, except those which should be legitimately
>>>> assigned
>>>> under the new methods.
>>>> John

  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message