lucene-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Mattmann, Chris A (388J)" <chris.a.mattm...@jpl.nasa.gov>
Subject Re: Changes Mess
Date Mon, 06 Dec 2010 03:36:29 GMT
Hi Steven,

Yep, like you state below JIRA *could* be configured to deal with this. 

In all honesty, putting tons of thought and effort into how to precisely deal with the changes
you specify below might be somewhat overkill.

Cheers,
Chris

On Dec 5, 2010, at 12:17 PM, Steven A Rowe wrote:

> 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
> 


++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
Chris Mattmann, Ph.D.
Senior Computer Scientist
NASA Jet Propulsion Laboratory Pasadena, CA 91109 USA
Office: 171-266B, Mailstop: 171-246
Email: chris.a.mattmann@nasa.gov
WWW:   http://sunset.usc.edu/~mattmann/
++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
Adjunct Assistant Professor, Computer Science Department
University of Southern California, Los Angeles, CA 90089 USA
++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++


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


Mime
View raw message