Mailing-List: contact java-dev-help@lucene.apache.org; run by ezmlm
Precedence: bulk
Reply-To: java-dev@lucene.apache.org
Received-SPF: pass (asf.osuosl.org: local policy)
Mime-Version: 1.0 (Apple Message framework v752.3)
In-Reply-To: 
 <392521EA2692A2418DF48C331E61E32522AB@professorville.windows.esseff.org>
References: 
 <392521EA2692A2418DF48C331E61E32522AB@professorville.windows.esseff.org>
Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed
Message-Id: <25ADF06E-F31C-4F83-9585-A4C516EFB492@ehatchersolutions.com>
Content-Transfer-Encoding: 7bit
From: Erik Hatcher <erik@ehatchersolutions.com>
Subject: Re: jira workflow
Date: Tue, 17 Oct 2006 09:12:23 -0400
To: java-dev@lucene.apache.org

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: java-dev-unsubscribe@lucene.apache.org
> For additional commands, e-mail: java-dev-help@lucene.apache.org


---------------------------------------------------------------------
To unsubscribe, e-mail: java-dev-unsubscribe@lucene.apache.org
For additional commands, e-mail: java-dev-help@lucene.apache.org