[ 
https://issues.apache.org/jira/browse/SOLR-10912?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16401355#comment-16401355
 ] 

Steve Rowe commented on SOLR-10912:
-----------------------------------

The short-term TODO is all taken care of:
{quote}
# Commit current patch to master
# Manually test the Jenkins precommit job
# Iterate above two steps until testing is successful
# Backport the patch to branch_7x
# Copy the Precommit-LUCENE-Build job to a new PreCommit-SOLR-Build job.
# Request ASF Infrastructure to add LUCENE and SOLR to the list of projects 
that use the PreCommit-Admin Jenkins job to enqueue precommit runs for new 
patches on LUCENE/SOLR JIRAs with the "Patch Available" state. (I'll make a 
JIRA for this and link it to this issue.)
# Attach a patch with the finalized Lucene/Solr personality on YETUS-537, for 
inclusion in future Yetus releases
{quote}

I'll leave this issue open until after automatic validation has started.

> 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
>            Assignee: Steve Rowe
>            Priority: Major
>         Attachments: SOLR-10912.ok-patch-in-core.patch, SOLR-10912.patch, 
> SOLR-10912.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]

Reply via email to