lucene-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Steven A Rowe <sar...@syr.edu>
Subject RE: Changes Mess
Date Sun, 05 Dec 2010 20:17:17 GMT
On 12/5/2010 at 12:19 PM, Robert Muir wrote:
> On Sun, Dec 5, 2010 at 12:08 PM, Mattmann, Chris A (388J)
> <chris.a.mattmann@jpl.nasa.gov> wrote:
> > Hi Mark,
> >
> > RE: the credit system. JIRA provides a contribution report here, like
> > this one that I generated for Lucene 3.1:
> >
> 
> My concern with this is that it leaves out important email contributors.

I agree, this is a serious problem.

My additional problems with JIRA-generated changes:

1. Huge undifferentiated change lists are frightening and nearly useless, regardless of the
quality of the descriptions.

	JIRA's issue types are:
	 
		Bug, New Feature, Improvement, Test, Wish, Task

	Even if we used JIRA's issue types to group issues, they
	are not the same as Lucene's CHANGES.txt issue types:

		Changes in backwards compatibility policy, 
		Changes in runtime behavior, 
		API Changes, Documentation, Bug fixes, New features,
		Optimizations, Build, Test Cases, Infrastructure

	(I left out Requirements, last used in 2006 under release
	1.9 RC1, since Build seems to have replaced it.)

2. There are now four separate CHANGES.txt files in the Lucene code base, excluding Solr and
its modules (each of which has one of them).  This number will only grow as more Lucene contribs
become modules.

	The JIRA project components list is outdated / incomplete
	/ has different granularity than the CHANGES.txt locations,
	so using it to group JIRA issues would not work because
	they don't align with Lucene/Solr components.

3. Some of the CHANGES.txt entries draw from multiple JIRA issues.

	From dev/trunk/lucene/CHANGES.txt:

		Trunk: 9 out of 56 include multiple JIRA issues
		3.X: 7/94
		3.0.0: 3/29
		2.9.0: 9/153

	I'm assuming a JIRA dump can't do this.

4. Some JIRA issues appear under multiple change categories in CHANGES.txt.

	From dev/trunk/lucene/CHANGES.txt:

		Trunk: 3 out of 68 multiply categorized
		3.X: 9/102
		3.0.0: 1/53
		2.9.0: 20/166

	A JIRA dump would not allow for multiple issue 
	categorization, since JIRA only allows a single issue
	type to be assigned - I guess they are assumed to be
	mutually exclusive.


Maybe our use of JIRA could be changed to address some of these problems, through addition
of new fields and/or modification of existing fields' allowable values?
	
Steve

Mime
View raw message