[ https://issues.apache.org/jira/browse/SOLR-10912?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16381324#comment-16381324 ]
Steve Rowe commented on SOLR-10912: ----------------------------------- bq. If there's not an entry in CHANGES.txt that mentions the issue number (either the lucene or solr file as appropriate), that should be a -1. I think -0 is warranted, but not -1; some committers' workflows order CHANGES additions after the initial commits, and non-committers rarely include CHANGES entries (maybe partly because committers have to change it, minimally to include their name). bq. How about a -1 if a SOLR patch makes changes to lucene, or vice versa? If there is an entry in the appropriate CHANGES.txt file for the issue, turn that into a -0. That way, we have better assurance that if a commit for one part of the project requires changes to the other part, there will be a release note. Some issues require changes in both places. Is there some issue you're trying to address besides release noting both projects? I ask because Solr users really need to pay attention to Lucene CHANGES regardless. > Adding automatic patch validation > --------------------------------- > > Key: SOLR-10912 > URL: https://issues.apache.org/jira/browse/SOLR-10912 > Project: Solr > Issue Type: Improvement > Security Level: Public(Default Security Level. Issues are Public) > Components: Build > Reporter: Mano Kovacs > Priority: Major > Attachments: SOLR-10912.ok-patch-in-core.patch, > SOLR-10912.sample-patch.patch, SOLR-10912.solj-contrib-facet-error.patch > > > Proposing introduction of automated patch validation, similar what Hadoop or > other Apache projects are using (see link). This would ensure that every > patch passes a certain set of criterions before getting approved. It would > save time for developer (faster feedback loop), save time for committers > (less step to do manually), and would increase quality. > Hadoop is currently using Apache Yetus to run validations, which seems to be > a good direction to start. This jira could be the board of discussing the > preferred solution. -- This message was sent by Atlassian JIRA (v7.6.3#76005) --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org