I closed PR #165, #146, #444, #711 and #651 I checked in the python script so you may try to run it for yourself
-- Jan Høydahl, search solution architect Cominvent AS - www.cominvent.com > 14. jun. 2019 kl. 13:20 skrev Jan Høydahl <[email protected]>: > > I wrote a script to find PRs without JIRA in title and to find PRs where > corresponding JIRA is closed. The output is below. > I could also extend the tool with options to also add a comment to the PRs > lacking issue in title, and to close the PRs where JIRA is resolved :) > > > usage: githubPRs.py [-h] [--json] [--token TOKEN] > > Find open Pull Requests that need attention > > optional arguments: > -h, --help show this help message and exit > --json Output as json > --token TOKEN Github access token in case you query too often anonymously > > > > Lucene/Solr Github PR report > ============================ > Number of open Pull Requests: 203 > Processing... > > PRs lacking JIRA reference in title > #717: Code cleanup - Avoid using stream filter count where possible > #711: Solr 12013 > #673: Replace instances of Math.random with Random.nextDouble > #669: Facet2d > #639: Solve the problem of highlighting Chinese inaccurately. > #622: Update Tessellator logic to label if triangle edges belongs to the > original polygon. > #615: Intervals Query Parser > #602: docu change: use class TopDocs instead of Hits > #601: Adding reader settings for moving fst offheap > #596: Under this branch, the dataDimensionCount is definitely not zero. > #595: Load freqs lazily in Postings > #564: prorated early termination > #542: LuceneLevenshteinDistance computes distance values outside of > interval [0, 1] > #508: Simplified JAVA_VER_NUM to utilize single expr execution > #507: Update jira/gradle to the latest master > #492: Answer to TODO: Replace Manual Encoding with JSON Module > #491: Update for multiple term's suggestion scoring > #484: solr 7.5 suggest The recommended result is empty > #478: Query Source Tracker custom component > #450: Add rule exception for "imento" and "mento" suffix > #442: Fixing an edge case bug when overriding a default > PostingsSolrHighligher > #415: Solr 12458 > #405: don't die when java prints tool options > #404: Comment to explain how to use URLClassifyProcessorFactory > #399: fix explicit type declaration > #393: Lucene 8347 > #388: Update package-info.java > #387: Solr-12421 > #383: In ContextQuery, use a more comprehensive check for an empty prefix > automaton. > #379: add ë, ö and ï to norm() > #350: SOLR match mode change for the rouding off instead of taking floor > #340: Add SolrConfig to SolrRequestParsers constructor in EmbeddedSolrServer > #309: Update ZkConfigManager.java > #308: Add a suggester that operates on tokenized values from a field > #293: spellcheck prefix already contains a trailing dot > #292: Removed extra whitespace > #272: Correct inconsistency on plugin support > #242: a little error about TopDocs > #241: SpanishLightStemmer fix for plural words like casas > #234: Made minor changes to docstring to fix wording errors > #231: WordDelimiterGraphFilter: Better support for camel case splitting. > #219: TieredMergePolicy.findMerges improvements > #218: feat: Separate SuggestModes for WordBreak and WordJoin > #217: added initial .travis.yml > #201: Allocate ArrayList with exact size > #175: Skipping merger > #153: Fix issues reported by findbugs > #152: Added log prior calculations in CachingNaiveBayesClassifier. > #133: Prevent memory leaks in PerFieldAnalyzerWrapper > #131: Fix peer sync replcation test check > #124: fix small issue in solr shell script > #116: fixed NPEs > #110: Update SearchFiles.java > #108: Minor - Fix error message > #85: Allow updating configs like port # on forced upgrade > #48: moved common string to constant file > #22: Update files.js > #8: Do not log error messages, if client has been interrupted > > Open PRs with a resolved JIRA > Processing... > #643: SOLR-13391 status=Resolved, resolution=Resolved, > resolutiondate=2019-04-12T14:09:27.000+0000 (SOLR-13391: Add variance and > standard deviation stream evaluators) > #444: SOLR-12708 status=Closed, resolution=Fixed, > resolutiondate=2019-03-19T03:46:31.000+0000 (SOLR-12708: Aggregate failures > from downstream async jobs; add error …) > #368: SOLR-12304 status=Resolved, resolution=Fixed, > resolutiondate=2019-05-17T03:15:01.000+0000 ([SOLR-12304] More Like This > component interesting term fix +tests) > #365: SOLR-12243 status=Closed, resolution=Fixed, > resolutiondate=2018-11-05T17:20:27.000+0000 ([SOLR-12243] span query > generalization + query parser tests) > #161: SOLR-9399 status=Closed, resolution=Fixed, > resolutiondate=2018-04-02T16:31:06.000+0000 (Fix SOLR-9399, pass basic auth > to update request) > #93: SOLR-8754 status=Resolved, resolution=Fixed, > resolutiondate=2019-06-13T10:59:41.000+0000 (SOLR-8754: Adding test cases and > additional error checking) > #651: LUCENE-8774 status=Closed, resolution=Duplicate, > resolutiondate=2019-04-28T20:00:27.000+0000 (LUCENE-8774: Performance > improvement for update?optimize=true) > #648: LUCENE-8766 status=Resolved, resolution=Fixed, > resolutiondate=2019-06-13T09:19:12.000+0000 (LUCENE-8766: Add Luwak as a > lucene module) > #631: LUCENE-8750 status=Resolved, resolution=Fixed, > resolutiondate=2019-04-03T09:19:47.000+0000 (LUCENE-8750: implement > setMissingValue for ValueSource sortFields) > #536: LUCENE-8643 status=Resolved, resolution=Fixed, > resolutiondate=2019-01-17T09:12:09.000+0000 (LUCENE-8643: Decrease test > complexity in the default case. Exclude simple text codec.) > #538: LUCENE-8640 status=Closed, resolution=Fixed, > resolutiondate=2019-01-28T19:30:32.000+0000 (LUCENE-8640: added changes for > the validation of valid dateString) > #533: LUCENE-8636 status=Resolved, resolution=Fixed, > resolutiondate=2019-01-15T11:02:49.000+0000 (LUCENE-8636: TestPointQueries > and long execution times) > #543: LUCENE-8474 status=Resolved, resolution=Fixed, > resolutiondate=2019-01-28T12:50:00.000+0000 (LUCENE-8474: final cleanups and > removal of RAMDirectory) > #432: LUCENE-8438 status=Resolved, resolution=Fixed, > resolutiondate=2019-01-28T12:52:44.000+0000 (LUCENE-8438: RAMDirectory speed > improvements and cleanup) > #146: LUCENE-7633 status=Closed, resolution=Won't Fix, > resolutiondate=2017-02-01T10:27:53.000+0000 (Rename Terms to IndexedField and > some related renamings, LUCENE-7633) > #141: LUCENE-7624 status=Closed, resolution=Fixed, > resolutiondate=2017-01-09T15:34:25.000+0000 (Minor corrections, see also > LUCENE-7624) > #165: LUCENE-7615 status=Resolved, resolution=Won't Fix, > resolutiondate=2018-04-02T19:38:51.000+0000 (LUCENE-7615 of 8 March 2017.) > #389: LUCENE-6687 status=Resolved, resolution=Fixed, > resolutiondate=2019-05-10T10:25:58.000+0000 ([LUCENE-6687] not necessary > nested for loop removed for terms retriev…) > #582: LUCENE-582 status=Closed, resolution=Fixed, > resolutiondate=2008-11-13T00:04:45.000+0000 (LUCENE-582: change heap array > init index to 1) > > -- > Jan Høydahl, search solution architect > Cominvent AS - www.cominvent.com <http://www.cominvent.com/> > >> 13. jun. 2019 kl. 22:56 skrev Cassandra Targett <[email protected] >> <mailto:[email protected]>>: >> >> I committed the pull request template a bit ago. Let’s see if it helps. >> >> I can help do some cleanup of existing open PRs, maybe tomorrow afternoon my >> time. It’s worth checking while we’re at it for PRs that are still open even >> though the Jira is resolved/closed. >> >> Cassandra >> On Jun 13, 2019, 6:08 AM -0500, Jan Høydahl <[email protected] >> <mailto:[email protected]>>, wrote: >>> Once we get C in place (Github PR template), this will hopefully fix itself. >>> So I propose to try PR template as a first measure and then revisit if that >>> is not enough. >>> >>> Still left to do is to triage the existing open PRs and link them. Who >>> wants to help? >>> >>> >>> https://github.com/apache/lucene-solr/pulls?utf8=✓&q=is%3Apr+is%3Aopen+NOT+LUCENE+in%3Atitle+AND+NOT+SOLR+in%3Atitle+ >>> >>> <https://github.com/apache/lucene-solr/pulls?utf8=%E2%9C%93&q=is%3Apr+is%3Aopen+NOT+LUCENE+in%3Atitle+AND+NOT+SOLR+in%3Atitle+> >>> >>> >>> We should probably also look for PRs with a LUCENE/SOLR jira attached, >>> where the fix is merged without auto-closing PR, and then close those. >>> >>> TIP: When you merge code outside of github, add the text "fixes #123" to >>> the commit message to automatically close PR#123. >>> >>> -- >>> Jan Høydahl, search solution architect >>> Cominvent AS - www.cominvent.com <http://www.cominvent.com/> >>> >>>> 10. jun. 2019 kl. 15:05 skrev Gus Heck <[email protected] >>>> <mailto:[email protected]>>: >>>> >>>> Or the committer can create it if the issue is truly trivial... Also, one >>>> of the things that folks who contribute may gain is learning about >>>> development process. That aspect was extremely helpful to me when I made >>>> my first contributions to Ant many years ago. Not everyone who contributes >>>> is an expert. >>>> >>>> On Mon, Jun 10, 2019 at 3:33 AM Varun Thacker <[email protected] >>>> <mailto:[email protected]>> wrote: >>>> I think D is important for making the barrier low for new contributors to >>>> get started. >>>> >>>> It won't be great as we'll have two places to look a CHANGES entry against >>>> but I'll be okay with that. >>>> >>>> Today a new contributor creates a PR and a committer can even merge the PR >>>> from the github interface. But in between those 2 steps we have to tell >>>> the contributor to go create a placeholder Jira. >>>> >>>> Imagine if this new contributor just wants to fix one typo from the ref >>>> guide. The overhead involved will shun quite a lot of folks? >>>> >>>> On Sat, Jun 8, 2019 at 2:22 PM Jan Høydahl <[email protected] >>>> <mailto:[email protected]>> wrote: >>>> Jira has become very heavy-weight over the years and I'm not sure we need >>>> all those features. >>>> I think Github issues are a bit too lightweight perhaps, so I'm not >>>> actively promoting option E, just lifting it up as a real alternative. >>>> >>>>> As an example how would you implement the security issue visibility with >>>>> original poster and PMC able to see it in github? >>>> >>>> Think they have something in the makings for this, see >>>> https://github.com/apache/lucene-solr/security/policy >>>> <https://github.com/apache/lucene-solr/security/policy> >>>> Have no idea if you can limit the group who sees them to PMC members >>>> though. >>>> >>>> -- >>>> Jan Høydahl, search solution architect >>>> Cominvent AS - www.cominvent.com <http://www.cominvent.com/> >>>> >>>> >>>> >>>> -- >>>> http://www.needhamsoftware.com <http://www.needhamsoftware.com/> (work) >>>> http://www.the111shift.com <http://www.the111shift.com/> (play) >>> >
