lucene-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Grant Ingersoll <>
Subject Re: jira workflow
Date Tue, 17 Oct 2006 14:29:50 GMT
Looking into the payload patch is next on my list after I finish up  
the benchmarking, but I know the payload patch is going to require  
several sets of eyes and some discussion.  I would like to see the  
more flexible index format addressed and I am not sure about the  
removal of Fieldable as an interface, but I admit I haven't looked  
into the depths just yet.  The reason I like Fieldable as an  
interface is I think it keeps us open to having Documents be backed  
by databases, etc. (I have been toying with the notion of DBFieldable  
which is a Fieldable implementation backed by a DB for seamless usage  
with a DB when creating Documents, but it isn't ready yet)

As for management, I think we could benefit some from getting some  
people to work toward a set of goals for improvements.  I can think  
of at least 3 major things (and I am sure others could add theirs)  
that would have significant impact:
1. Flexible Indexing
2. Java 1.5
3.  Merge improvements suggested by Dave Balmain and Marvin Humphrey  
concerning segments and also storing vector information outside of  
the merge segments.

We have some planning docs on the Wiki, but I don't think anyone has  
really taken up that torch.


On Oct 17, 2006, at 9:12 AM, Erik Hatcher wrote:

> Steven,
> Thanks for this prod.  I've been meaning to debrief the Lucene dev  
> group on a recent visit I made to IBM's Silicon Valley Labs where I  
> presented Lucene and met with their search gurus.  A recurring  
> theme from them was the management of Java Lucene project, and what  
> they and we can do to better have patches applied and move Lucene  
> forward.
> For example, the payload design proposed by one of the SVL team  
> members is something they really need to accomplish clever XML  
> indexing, and we've not done anything about it even though the  
> proposal was backwards compatible and added something valuable to  
> Lucene.  Granted, that did open the discussion up into a more  
> generalized "flexible index format" topic, but that has yet to  
> become real code.
> I am all for us adopting the JIRA techniques that Hadoop uses, and  
> for us committers (and contributors) to become more efficient and  
> effective with patch and release management.
> Now all we need are volunteers to facilitate this.  I'd love to  
> help more, but I'm much too frazzled and swamped to manage  
> something like this myself currently.  But I strongly support it!
> 	Erik
> On Oct 17, 2006, at 8:19 AM, Steven Parkes wrote:
>> As a member of a number of Lucene subprojects dev lists, I've been
>> comparing the way the Jira workflow is used on the different  
>> projects.
>> In particular, I've been noting the difference between the workflows
>> that Lucene Java and Hadoop use.  Hadoop in particular has a state  
>> for
>> "patch submitted" which, as it's used on Hadoop, seems to facilitate
>> communication. State changes (open->patch submitted,
>> patch-submitted->open) seem to help communications between  
>> contributors
>> and reviewers. Looking at the Lucene Java Jira, sometimes  
>> "[patch]" is
>> put at the beginning of the description of the issue to indicate
>> something similar, but this isn't used too consistently and  
>> doesn't seem
>> to be as effective. It also requires custom filters to easily see all
>> issues in the "patch submitted" state.
>> Is there sufficient interest to consider this for Lucene Java? (I'd
>> write "any interest", but since I'm interested, there's at least  
>> some.)
>> There are a couple of issues around the Hadoop workflow I'm aware of.
>> One is that once an issue is closed, it can't be reopened. As I
>> understand it, this is because on Hadoop, they use the Jira feature
>> which allows automated generation of release notes. As someone who is
>> responsible for tracking the changes between releases for my company,
>> this is actually a win for me, so I like the way Hadoop does it.  
>> But it
>> does add the step of needing to start a new Jira issue rather than  
>> just
>> reopening an old one.
>> The other thing I was thinking of was the case where we say "if  
>> you're
>> working on something, go ahead and submit a patch even if it's not
>> polished or you aren't sure you want it to be a candidate for the  
>> trunk.
>> Let others look at it." I think that's clearly a good thing to  
>> have, but
>> I wonder what the best way to handle it in Jira is. What state  
>> should be
>> used?
>> There are quite a few open issues in Jira. Makes me a little
>> uncomfortable, since in my experience, when you get really long  
>> lists of
>> issues that are not addressed, the effectiveness of an issue tracking
>> system seems to drop dramatically. Anybody else think this? I've got
>> time to contribute to cleanup if there's sufficient interest.
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail:
>> For additional commands, e-mail:
> ---------------------------------------------------------------------
> To unsubscribe, e-mail:
> For additional commands, e-mail:

Grant Ingersoll
Sr. Software Engineer
Center for Natural Language Processing
Syracuse University
335 Hinds Hall
Syracuse, NY 13244

To unsubscribe, e-mail:
For additional commands, e-mail:

View raw message