On Mon, Dec 6, 2010 at 9:56 AM, Mattmann, Chris A (388J) <[email protected]> wrote:
> What's the difference between Mike going and writing up a more informative > CHANGES.txt entry than say updating JIRA with the information from that entry > to have a more descriptive title? > Well, you are right, but its another modification to JIRA (an edit). And then there are more examples like this: CHANGES: * LUCENE-2650: Added extra safety to MMapIndexInput clones to prevent accessing an unmapped buffer if the input is closed JIRA: * LUCENE-2650: improve windows defaults in FSDirectory The jira is *CORRECT*. While working on the issue i discovered we could trivially add some extra safety. So i backported the extra safety to all branches. In this case i would have to split my patch in half and create another JIRA issue for this very trivial change? Just saying, to do what you are saying (by the way, I'm not opposed to the idea!), we would have to change the way we use JIRA and increase noise to the mailing list. There are quite a few examples like this: e.g. this "jira release notes" say this: [LUCENE-2055] - Fix buggy stemmers and Remove duplicate analysis functionality. But i certainly didn't do this in a bugfix release! what actually happened is in contrib/CHANGES.txt: * LUCENE-2055: Add documentation noting that the Dutch and French stemmers in contrib/analyzers do not implement the Snowball algorithm correctly, and recommend to use the equivalents in contrib/snowball if possible. So I don't know how jira would handle this case? because we merged contrib/snowball with contrib/analyzers in 3.1 i would have to create a separate jira issue just so that 3.1 has the correct description/path name in its release notes? and in 4.0 i'd have to create a third duplicate JIRA issue because we merged all the analyzers, so there it needs to refer to modules/analysis? --------------------------------------------------------------------- To unsubscribe, e-mail: [email protected] For additional commands, e-mail: [email protected]
