[
https://issues.apache.org/jira/browse/SOLR-13952?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16981161#comment-16981161
]
David Smiley commented on SOLR-13952:
-------------------------------------
I'm frustrated. Did you read my message? You committed to master what I asked
you not to do. It's a lot about the commit message. Imagine you are looking
at the change history for a file and looking over the commit messages. Why
should this commit message even mention gradle? It has nothing to do with
Gradle. It should mention what it *does*. Like... "Adding @SuppressWarnings".
Even list a bunch of things bulleted if you wish. First line is most
important; probably minor non-functional edits or some-such. Can you
appreciate my point?
> Separate out Gradle-specific code from other (mostly test) changes and commit
> separately
> ----------------------------------------------------------------------------------------
>
> Key: SOLR-13952
> URL: https://issues.apache.org/jira/browse/SOLR-13952
> Project: Solr
> Issue Type: Task
> Security Level: Public(Default Security Level. Issues are Public)
> Components: Build
> Reporter: Erick Erickson
> Assignee: Erick Erickson
> Priority: Major
> Attachments: SOLR-13952.patch, fordavid.patch
>
>
> The gradle_8 branch has many changes unrelated to gradle. It would be much
> easier to work on the gradle parts if these were separated. So here's my plan:
> This turned out not to be as hard as I expected. I'll create a sub-task for
> the functional changes and use this one for the non-functional changes.
> Non-functional changes are the overwhelming majority of changes. There are a
> few categories of change here:
> * SuppressWarnings, rawtypes, deprecated.
> * SuppressWarnings for known thread leaks by adding SolrIgnoreThreadsFilter
> and QuickPatchThreadsFilter. These are know thread leaks from third-party
> products (IBM Java, and a Log4J2 thread was added)
> * some static imports were removed
> * some reformatting, given that this whole patch is not about functional
> changes I decided to leave them in.
> * Some very minor code changes:
> ** change "new Path(leaderPath).getParent().toString();" to
> "Paths.get(leaderPath).getParent().toString();"
> ** mods like new HashMap(); <- new HashMap<>();
> * Log messages added
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
---------------------------------------------------------------------
To unsubscribe, e-mail: issues-unsubscr...@lucene.apache.org
For additional commands, e-mail: issues-h...@lucene.apache.org
