[ https://issues.apache.org/jira/browse/SOLR-10912?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16381062#comment-16381062 ]
Shawn Heisey commented on SOLR-10912: ------------------------------------- Some thoughts: 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. 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. I'm pretty sure that votes made by this QA mechanism wouldn't be binding, but it would be a good idea to achieve a +1 from it if possible, and when it's not, there should be a very good and well-documented reason. > 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