[
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: [email protected]
For additional commands, e-mail: [email protected]
