[
https://issues.apache.org/jira/browse/SOLR-10912?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16382093#comment-16382093
]
Shawn Heisey commented on SOLR-10912:
-------------------------------------
On what to do if there's no CHANGES.txt entry: The goal is to make sure the
changelog update doesn't fall through the cracks and get forgotten. If the -0
accomplishes that, then that's great.
bq. 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.
I'm not trying to prevent one issue changing both sections of the codebase,
just trying to make sure that if it happens, there's an explicit note in both
changelogs. Obviously a lot of LUCENE changes directly affect Solr even if
they don't change Solr code, and for those, only updating the Lucene changelog
is the right thing to do, and it's up to Solr users to read Lucene's changelog.
But if an issue on one part of the project actually makes changes to the code
in the other, I think the documentation bar should be a little bit higher.
Additional idea: Record a -1 if a SOLR issue *only* makes changes to Lucene
code, or vice versa. But when this happens, a changelog entry won't be enough
to adjust to -0.
> 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]
