Solr
  1. Solr
  2. SOLR-6624

Spelling mistakes in the Java source

    Details

    • Type: Bug Bug
    • Status: Closed
    • Priority: Trivial Trivial
    • Resolution: Fixed
    • Affects Version/s: 6.0
    • Fix Version/s: 5.0, 6.0
    • Component/s: None
    • Labels:

      Description

      I found spelling mistakes in the Solr java source files viz. recieved instead of received.

      1. solr-6624.patch
        3 kB
        Hrishikesh Gadre
      2. SweetSpotSimilarityFactory.patch
        8 kB
        Ahmet Arslan

        Activity

        Hide
        Gregory Chanan added a comment -

        +1.

        Show
        Gregory Chanan added a comment - +1.
        Hide
        ASF subversion and git services added a comment -

        Commit 1631924 from gchanan@apache.org in branch 'dev/trunk'
        [ https://svn.apache.org/r1631924 ]

        SOLR-6624: Spelling mistakes in the Java source

        Show
        ASF subversion and git services added a comment - Commit 1631924 from gchanan@apache.org in branch 'dev/trunk' [ https://svn.apache.org/r1631924 ] SOLR-6624 : Spelling mistakes in the Java source
        Hide
        Ahmet Arslan added a comment -

        a few typos more

        Show
        Ahmet Arslan added a comment - a few typos more
        Hide
        Yonik Seeley added a comment -

        Feel free to just report spelling mistakes on the mailing lists... we don't have to go through JIRA for trivial changes.

        Oh, and we shouldn't add CHANGES.txt entries for trivial changes either... source code control systems keep an exhaustive list for those who are really interested.

        Show
        Yonik Seeley added a comment - Feel free to just report spelling mistakes on the mailing lists... we don't have to go through JIRA for trivial changes. Oh, and we shouldn't add CHANGES.txt entries for trivial changes either... source code control systems keep an exhaustive list for those who are really interested.
        Hide
        Mark Miller added a comment -

        If you are a committer I agree. If not, I don't. An email about a fix is easily ignored and lost. And any contribution, no matter how small, should go into changes as credit IMO. This is exactly what the trivial priority is for.

        Show
        Mark Miller added a comment - If you are a committer I agree. If not, I don't. An email about a fix is easily ignored and lost. And any contribution, no matter how small, should go into changes as credit IMO. This is exactly what the trivial priority is for.
        Hide
        Yonik Seeley added a comment -

        And any contribution, no matter how small, should go into changes as credit IMO.

        I disagree. CHANGES serves a dual purpose. The primary purpose is for users to read through to discover non-trivial changes and bug fixes. The secondary purpose is to give credit to contributions, but we only tack those on if it's a change that merits going into CHANGES in the first place. Trivial changes should not be added to CHANGES. If people are interested in them, we can give a URL that has everything (or we can programmatically construct it).

        There have been tons of spelling mistakes and people pointing them out in the past. This is the first time an entry into CHANGES has been made.

        /opt/code/heliosearch/solr$ grep -i spelling CHANGES.txt
        * SOLR-6624 Spelling mistakes in the Java source (Hrishikesh Gadre)
        * SOLR-2585: Context-Sensitive Spelling Suggestions & Collations.  This adds support
        * SOLR-2576: Remove deprecated SpellingResult.add(Token, int).
        * SOLR-2576: Deprecate SpellingResult.add(Token token, int docFreq), please use
          SpellingResult.addFrequency(Token token, int docFreq) instead.
          methods using the new SpellingOptions class, but are not required to.  While this change is
          backward compatible, the trunk version of Solr has already dropped support for all but the SpellingOptions method. (gsingers)
        57. SOLR-1204: Enhance SpellingQueryConverter to handle UTF-8 instead of ASCII only.
        52. SOLR-572: Added SpellCheckComponent and org.apache.solr.spelling package to support more spell 
        
        Show
        Yonik Seeley added a comment - And any contribution, no matter how small, should go into changes as credit IMO. I disagree. CHANGES serves a dual purpose. The primary purpose is for users to read through to discover non-trivial changes and bug fixes. The secondary purpose is to give credit to contributions, but we only tack those on if it's a change that merits going into CHANGES in the first place. Trivial changes should not be added to CHANGES. If people are interested in them, we can give a URL that has everything (or we can programmatically construct it). There have been tons of spelling mistakes and people pointing them out in the past. This is the first time an entry into CHANGES has been made. /opt/code/heliosearch/solr$ grep -i spelling CHANGES.txt * SOLR-6624 Spelling mistakes in the Java source (Hrishikesh Gadre) * SOLR-2585: Context-Sensitive Spelling Suggestions & Collations. This adds support * SOLR-2576: Remove deprecated SpellingResult.add(Token, int ). * SOLR-2576: Deprecate SpellingResult.add(Token token, int docFreq), please use SpellingResult.addFrequency(Token token, int docFreq) instead. methods using the new SpellingOptions class, but are not required to. While this change is backward compatible, the trunk version of Solr has already dropped support for all but the SpellingOptions method. (gsingers) 57. SOLR-1204: Enhance SpellingQueryConverter to handle UTF-8 instead of ASCII only. 52. SOLR-572: Added SpellCheckComponent and org.apache.solr.spelling package to support more spell
        Hide
        Shalin Shekhar Mangar added a comment -

        I agree with Yonik. Fixing typos (and code formatting) shouldn't be required to go via Jira and they don't belong in the change log.

        Show
        Shalin Shekhar Mangar added a comment - I agree with Yonik. Fixing typos (and code formatting) shouldn't be required to go via Jira and they don't belong in the change log.
        Hide
        Gregory Chanan added a comment -

        Thanks for the feedback Yonik, Mark, and Shalin.

        Not outright requiring a JIRA seems fine, though for me personally I'd end up filing them since it doesn't take much longer than sending an e-mail, gives a a central place for discussion (like this one!) that won't be lost in the depths of mail archives, and gives a a referenceable name. Seems the benefit outweighs the cost to me.

        On modifying CHANGES.txt I'm sensitive to to the concerns of keeping the changes in CHANGES.txt significant while also giving credit to contributors. Perhaps it makes sense it cases like this to just include the contributors name in the commit message [i.e. "SOLR-6624: Spelling mistakes in the Java source (Hrishikesh)]" and not add it to the CHANGES.txt? Thoughts?

        Show
        Gregory Chanan added a comment - Thanks for the feedback Yonik, Mark, and Shalin. Not outright requiring a JIRA seems fine, though for me personally I'd end up filing them since it doesn't take much longer than sending an e-mail, gives a a central place for discussion (like this one!) that won't be lost in the depths of mail archives, and gives a a referenceable name. Seems the benefit outweighs the cost to me. On modifying CHANGES.txt I'm sensitive to to the concerns of keeping the changes in CHANGES.txt significant while also giving credit to contributors. Perhaps it makes sense it cases like this to just include the contributors name in the commit message [i.e. "SOLR-6624: Spelling mistakes in the Java source (Hrishikesh)] " and not add it to the CHANGES.txt? Thoughts?
        Hide
        Mark Miller added a comment -

        Jiras are up to the individual. Email is a poor substitute. A JIRA is not required, but a good idea if you actually want to see something changed.

        For credit, there is plenty of insignificant stuff in Other. If a non committer is willing to take the time to contribute, we should credit them in CHANGES. I'll stick to erroring on providing credit to contributors for positive changes to the code.

        In the end it is up to each committer. Personal, I won't waste my time trying to minimize anyone's contributions. Changes is as much about credit for non committers as anything. If someone takes the time to make a patch, into changes I'll put them.

        Show
        Mark Miller added a comment - Jiras are up to the individual. Email is a poor substitute. A JIRA is not required, but a good idea if you actually want to see something changed. For credit, there is plenty of insignificant stuff in Other. If a non committer is willing to take the time to contribute, we should credit them in CHANGES. I'll stick to erroring on providing credit to contributors for positive changes to the code. In the end it is up to each committer. Personal, I won't waste my time trying to minimize anyone's contributions. Changes is as much about credit for non committers as anything. If someone takes the time to make a patch, into changes I'll put them.
        Hide
        ASF subversion and git services added a comment -

        Commit 1632453 from gchanan@apache.org in branch 'dev/branches/branch_5x'
        [ https://svn.apache.org/r1632453 ]

        SOLR-6624: Spelling mistakes in the Java source

        Show
        ASF subversion and git services added a comment - Commit 1632453 from gchanan@apache.org in branch 'dev/branches/branch_5x' [ https://svn.apache.org/r1632453 ] SOLR-6624 : Spelling mistakes in the Java source
        Hide
        Gregory Chanan added a comment -

        Committed to 5.0 and trunk, thanks for the patch Hrishikesh.

        Show
        Gregory Chanan added a comment - Committed to 5.0 and trunk, thanks for the patch Hrishikesh.
        Hide
        Anshum Gupta added a comment -

        Bulk close after 5.0 release.

        Show
        Anshum Gupta added a comment - Bulk close after 5.0 release.

          People

          • Assignee:
            Gregory Chanan
            Reporter:
            Hrishikesh Gadre
          • Votes:
            0 Vote for this issue
            Watchers:
            8 Start watching this issue

            Dates

            • Created:
              Updated:
              Resolved:

              Development