On 12/5/2010 at 12:19 PM, Robert Muir wrote:
> On Sun, Dec 5, 2010 at 12:08 PM, Mattmann, Chris A (388J)
> <[email protected]> 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