: I thought it is an extremely trivial fix. That's why I didn't add it to : changes.txt. I shall do it
To elaborate my thoughts: there are really 2 key issues why i think this deserse a CHANGES.txt entry: 1) anytime we fix a bug that affects previously released versions of Solr, there should be *something* related to it in CHANGES.txt. If a bug was found & tracked in it's own Jira until fixed, then it should almost certainly be it's own entry in CHANGES.txt if for no other reason then so people who see the jira emails/records can easily find it. Frequently small bugs like this might be fixed as part of a larger bug fix or new feature that refactors a lot of code -- in which case that larger bug/feature's CHANGES.txt entry already notes the relevant change summary, so an individual entry may not be needed. It depends on how impactful/common the bug was. remember: people look at CHANGES.txt to decide if/when it's worth their effort to upgrade, if there's a bug/glitch that's affecting them, and your CHANGES.txt entry makes them think "ah, i bet that's what's causin hte weird behavior i'm seeing! yea it's been fixed!!" that helps people a lot. 2) any time a contributor provides code, they *MUST* get credit for their contribution. As a committer, if you are making minor tweaks or cleanup or fixing a small thing as part of a larger change, you can always choose not to bother tooting your own horn about every little change you make if ou don't think it warrants special attention based on the point #1 guidelines i was mentioning above -- but when you are acting as the agent of another contributor by committing their code, you really must give them credit in CHANGES.txt : On Sep 5, 2014 7:15 PM, "Hoss Man (JIRA)" <[email protected]> wrote: : : > : > [ : > https://issues.apache.org/jira/browse/SOLR-6457?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel : > ] : > : > Hoss Man reopened SOLR-6457: : > ---------------------------- : > : > This needs a CHANGES.txt noting the bug fix and giving longkeyy credit for : > the contribution. : > : > > LBHttpSolrServer: AIOOBE risk if counter overflows : > > -------------------------------------------------- : > > : > > Key: SOLR-6457 : > > URL: https://issues.apache.org/jira/browse/SOLR-6457 : > > Project: Solr : > > Issue Type: Bug : > > Components: clients - java : > > Affects Versions: 4.0, 4.1, 4.2, 4.2.1, 4.3, 4.3.1, 4.4, 4.5, 4.5.1, : > 4.6, 4.6.1, 4.7, 4.7.1, 4.7.2, 4.8, 4.8.1, 4.9 : > > Reporter: longkeyy : > > Assignee: Noble Paul : > > Labels: patch : > > Attachments: SOLR-6457.patch : > > : > > : > > org.apache.solr.client.solrj.impl.LBHttpSolrServer : > > line 442 : > > int count = counter.incrementAndGet(); : > > ServerWrapper wrapper = serverList[count % serverList.length]; : > > when counter overflows, the mod operation of : > > "count % serverList.length" will start trying to use negative numbers as : > array indexes. : > > suggess to fixup it ,eg: : > > //keep count is greater than 0 : > > int count = counter.incrementAndGet() & 0x7FFFFFF; : > : > : > : > -- : > This message was sent by Atlassian JIRA : > (v6.3.4#6332) : > : > --------------------------------------------------------------------- : > To unsubscribe, e-mail: [email protected] : > For additional commands, e-mail: [email protected] : > : > : -Hoss http://www.lucidworks.com/ --------------------------------------------------------------------- To unsubscribe, e-mail: [email protected] For additional commands, e-mail: [email protected]
