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.mattm...@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.mattm...@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-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
