Mailing List Archive

Closing GitHub PRs
Hi

I ran the tool dev-tools/scripts/githubPRs.py and JIRA and GitHub tend to diverge day by day. Need some help to connect orphan PRs with JIRA issues and close PRs that have a closed JIRA:

PRs lacking JIRA reference in title
#1026: Buffer one record from each shard every 5000 reads to ensure connecti…
#1005: LUCENE 9042: Refactor TopGroups.merge tests
#1002: [docs]: fixed two small errors in JavaDoc
#1000: [MINOR] Fix typo
#993: maybe can simpler
#988: Update README.md
#934: Fix typo
#908: Change the file format of README files from README.txt to README.md a…
#882: Add versions.lock entry for "org.apache.yetus:audience-annotations"
#880: Tweak header format.
#873: Rename README.txt to README.md
#854: Shared PQ Based Early Termination for Concurrent Search
#807: Remove solr.jetty.https.port when SSL is not used
#772: Payload-stored position length intervals
#673: Replace instances of Math.random with Random.nextDouble
#669: Facet2d
#639: Solve the problem of highlighting Chinese inaccurately.
#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.
#564: prorated early termination
#542: LuceneLevenshteinDistance computes distance values outside of interval [0, 1]
#508: Simplified JAVA_VER_NUM to utilize single expr execution
#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
#405: don't die when java prints tool options
#404: Comment to explain how to use URLClassifyProcessorFactory
#399: fix explicit type declaration
#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
#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.
#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
#365: SOLR-12243 status=Closed, resolution=Fixed, resolutiondate=2018-11-05T17:20:27.000+0000 ([SOLR-12243] span query generalization + query parser tests)
#330: SOLR-12045 status=Closed, resolution=Won't Fix, resolutiondate=2019-11-02T15:24:54.000+0000 (SOLR-12045: Moving the Analytics Component from contrib to core.)
#861: SOLR-10665 status=Resolved, resolution=Abandoned, resolutiondate=2019-11-12T03:25:46.000+0000 (SOLR-10665 POC for a PF4J based plugin system)
#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=Closed, resolution=Fixed, resolutiondate=2019-06-13T10:59:41.000+0000 (SOLR-8754: Adding test cases and additional error checking)
#1032: LUCENE-9058 status=Resolved, resolution=Won't Fix, resolutiondate=2019-11-25T18:58:49.000+0000 (LUCENE-9058: highlighting over underneath field despite IQ field)
#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.)
#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)

--
Jan Høydahl, search solution architect
Cominvent AS - www.cominvent.com
Re: Closing GitHub PRs [ In reply to ]
I have a PR without a jira ticket, I’ll update the title of the PR.

On Tue, Nov 26, 2019 at 3:02 PM Jan Høydahl <jan.asf@cominvent.com> wrote:

> Hi
>
> I ran the tool dev-tools/scripts/githubPRs.py and JIRA and GitHub tend to
> diverge day by day. Need some help to connect orphan PRs with JIRA issues
> and close PRs that have a closed JIRA:
>
> PRs lacking JIRA reference in title
> #1026: Buffer one record from each shard every 5000 reads to ensure
> connecti…
> #1005: LUCENE 9042: Refactor TopGroups.merge tests
> #1002: [docs]: fixed two small errors in JavaDoc
> #1000: [MINOR] Fix typo
> #993: maybe can simpler
> #988: Update README.md
> #934: Fix typo
> #908: Change the file format of README files from README.txt to
> README.md a…
> #882: Add versions.lock entry for "org.apache.yetus:audience-annotations"
> #880: Tweak header format.
> #873: Rename README.txt to README.md
> #854: Shared PQ Based Early Termination for Concurrent Search
> #807: Remove solr.jetty.https.port when SSL is not used
> #772: Payload-stored position length intervals
> #673: Replace instances of Math.random with Random.nextDouble
> #669: Facet2d
> #639: Solve the problem of highlighting Chinese inaccurately.
> #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.
> #564: prorated early termination
> #542: LuceneLevenshteinDistance computes distance values outside of
> interval [0, 1]
> #508: Simplified JAVA_VER_NUM to utilize single expr execution
> #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
> #405: don't die when java prints tool options
> #404: Comment to explain how to use URLClassifyProcessorFactory
> #399: fix explicit type declaration
> #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
> #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.
> #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
> #365: SOLR-12243 status=Closed, resolution=Fixed,
> resolutiondate=2018-11-05T17:20:27.000+0000 ([SOLR-12243] span query
> generalization + query parser tests)
> #330: SOLR-12045 status=Closed, resolution=Won't Fix,
> resolutiondate=2019-11-02T15:24:54.000+0000 (SOLR-12045: Moving the
> Analytics Component from contrib to core.)
> #861: SOLR-10665 status=Resolved, resolution=Abandoned,
> resolutiondate=2019-11-12T03:25:46.000+0000 (SOLR-10665 POC for a PF4J
> based plugin system)
> #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=Closed, resolution=Fixed,
> resolutiondate=2019-06-13T10:59:41.000+0000 (SOLR-8754: Adding test cases
> and additional error checking)
> #1032: LUCENE-9058 status=Resolved, resolution=Won't Fix,
> resolutiondate=2019-11-25T18:58:49.000+0000 (LUCENE-9058: highlighting over
> underneath field despite IQ field)
> #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.)
> #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)
>
> --
> Jan Høydahl, search solution architect
> Cominvent AS - www.cominvent.com
>
> --
Sent from Gmail for IPhone
Re: Closing GitHub PRs [ In reply to ]
I have closed several PRs where JIRAs were closed.
Also merged several minor PRs with typo fixes and similar, without opening a JIRA for them.
Would be nice for our first-time contributors if they get an immediate response when opening a PR!

The updated list of PRs we still have to triage are now:

Lucene/Solr Github PR report
============================
Number of open Pull Requests: 233

PRs lacking JIRA reference in title
#1026: Buffer one record from each shard every 5000 reads to ensure connecti…
#1005: LUCENE 9042: Refactor TopGroups.merge tests
#1002: [docs]: fixed two small errors in JavaDoc
#993: maybe can simpler
#988: Update README.md
#908: Change the file format of README files from README.txt to README.md a…
#882: Add versions.lock entry for "org.apache.yetus:audience-annotations"
#880: Tweak header format.
#873: Rename README.txt to README.md
#854: Shared PQ Based Early Termination for Concurrent Search
#807: Remove solr.jetty.https.port when SSL is not used
#772: Payload-stored position length intervals
#673: Replace instances of Math.random with Random.nextDouble
#669: Facet2d
#639: Solve the problem of highlighting Chinese inaccurately.
#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.
#564: prorated early termination
#542: LuceneLevenshteinDistance computes distance values outside of interval [0, 1]
#508: Simplified JAVA_VER_NUM to utilize single expr execution
#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
#405: don't die when java prints tool options
#404: Comment to explain how to use URLClassifyProcessorFactory
#399: fix explicit type declaration
#383: In ContextQuery, use a more comprehensive check for an empty prefix automaton.
#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
#241: SpanishLightStemmer fix for plural words like casas
#231: WordDelimiterGraphFilter: Better support for camel case splitting.
#218: feat: Separate SuggestModes for WordBreak and WordJoin
#201: Allocate ArrayList with exact size
#175: Skipping merger
#153: Fix issues reported by findbugs
#152: Added log prior calculations in CachingNaiveBayesClassifier.
#131: Fix peer sync replcation test check
#124: fix small issue in solr shell script
#110: Update SearchFiles.java
#85: Allow updating configs like port # on forced upgrade
#48: moved common string to constant file
#8: Do not log error messages, if client has been interrupted

Open PRs with a resolved JIRA
#365: SOLR-12243 status=Closed, resolution=Fixed, resolutiondate=2018-11-05T17:20:27.000+0000 ([SOLR-12243] span query generalization + query parser tests)
#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.)
#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)


--
Jan Høydahl, search solution architect
Cominvent AS - www.cominvent.com

> 26. nov. 2019 kl. 22:18 skrev Man with No Name <pinkeshsharma89@gmail.com>:
>
> I have a PR without a jira ticket, I’ll update the title of the PR.
>
> On Tue, Nov 26, 2019 at 3:02 PM Jan Høydahl <jan.asf@cominvent.com <mailto:jan.asf@cominvent.com>> wrote:
> Hi
>
> I ran the tool dev-tools/scripts/githubPRs.py and JIRA and GitHub tend to diverge day by day. Need some help to connect orphan PRs with JIRA issues and close PRs that have a closed JIRA:
>
> PRs lacking JIRA reference in title
> #1026: Buffer one record from each shard every 5000 reads to ensure connecti…
> #1005: LUCENE 9042: Refactor TopGroups.merge tests
> #1002: [docs]: fixed two small errors in JavaDoc
> #1000: [MINOR] Fix typo
> #993: maybe can simpler
> #988: Update README.md
> #934: Fix typo
> #908: Change the file format of README files from README.txt to README.md a…
> #882: Add versions.lock entry for "org.apache.yetus:audience-annotations"
> #880: Tweak header format.
> #873: Rename README.txt to README.md
> #854: Shared PQ Based Early Termination for Concurrent Search
> #807: Remove solr.jetty.https.port when SSL is not used
> #772: Payload-stored position length intervals
> #673: Replace instances of Math.random with Random.nextDouble
> #669: Facet2d
> #639: Solve the problem of highlighting Chinese inaccurately.
> #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.
> #564: prorated early termination
> #542: LuceneLevenshteinDistance computes distance values outside of interval [0, 1]
> #508: Simplified JAVA_VER_NUM to utilize single expr execution
> #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
> #405: don't die when java prints tool options
> #404: Comment to explain how to use URLClassifyProcessorFactory
> #399: fix explicit type declaration
> #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
> #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.
> #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
> #365: SOLR-12243 status=Closed, resolution=Fixed, resolutiondate=2018-11-05T17:20:27.000+0000 ([SOLR-12243] span query generalization + query parser tests)
> #330: SOLR-12045 status=Closed, resolution=Won't Fix, resolutiondate=2019-11-02T15:24:54.000+0000 (SOLR-12045: Moving the Analytics Component from contrib to core.)
> #861: SOLR-10665 status=Resolved, resolution=Abandoned, resolutiondate=2019-11-12T03:25:46.000+0000 (SOLR-10665 POC for a PF4J based plugin system)
> #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=Closed, resolution=Fixed, resolutiondate=2019-06-13T10:59:41.000+0000 (SOLR-8754: Adding test cases and additional error checking)
> #1032: LUCENE-9058 status=Resolved, resolution=Won't Fix, resolutiondate=2019-11-25T18:58:49.000+0000 (LUCENE-9058: highlighting over underneath field despite IQ field)
> #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.)
> #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)
>
> --
> Jan Høydahl, search solution architect
> Cominvent AS - www.cominvent.com <http://www.cominvent.com/>
>
> --
> Sent from Gmail for IPhone
Re: Closing GitHub PRs [ In reply to ]
Could we maybe instead bulk-add a comment explaining the split and how to
take the PR forwards if someone (in the future) has itch/time?

I know we humans love to clean things up, but I think leaving such
"unclean" things open serves an important purpose. They all had importance
to at least one person at one point in time, and likely many of them are
still relevant if they piqued someones curiosity to dig back into them.
Closing them makes them harder to find for the future developer.

I'm sure some of them are already resolved/duplicates too. If only we
could divine which are which.

Mike McCandless

http://blog.mikemccandless.com


On Mon, Nov 29, 2021 at 2:45 PM Mike Drob <mdrob@mdrob.com> wrote:

> We currently have almost 300 open PRs against the "master" branch in the
> old lucene-solr repo.
>
>
> https://github.com/apache/lucene-solr/pulls?q=is%3Apr+is%3Aopen+base%3Amaster
>
> I think we should close all of them (possibly with a comment pointing
> people to the main branch in the lucene or solr repos).
>
> I do not know if there is an automated way to do this, or a way to do this
> without spamming everybody's email lists. If there is consensus on this
> clean up work then I'll take some time to investigate how to get this done
> and/or chat with ASF Infra about it.
>
> Thanks,
> Mike
>
Re: Closing GitHub PRs [ In reply to ]
On Mon, Nov 29, 2021 at 2:49 PM Michael McCandless
<lucene@mikemccandless.com> wrote:
>
> Could we maybe instead bulk-add a comment explaining the split and how to take the PR forwards if someone (in the future) has itch/time?
>
> I know we humans love to clean things up, but I think leaving such "unclean" things open serves an important purpose. They all had importance to at least one person at one point in time, and likely many of them are still relevant if they piqued someones curiosity to dig back into them. Closing them makes them harder to find for the future developer.
>
> I'm sure some of them are already resolved/duplicates too. If only we could divine which are which.
>
>

+1, I'd rather not auto-close PRs. I'm always frustrated by this when
I see it in other trackers. Is there a rush to close these for some
reason?

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@lucene.apache.org
For additional commands, e-mail: dev-help@lucene.apache.org
Re: Closing GitHub PRs [ In reply to ]
I understand the frustrations around closing somebody’s PR as stale, but I
also think that there is value in informing the contributors I this is
never getting solved/fixed/looked at, if this is still important please go
over there instead.

On Mon, Nov 29, 2021 at 1:55 PM Robert Muir <rcmuir@gmail.com> wrote:

> On Mon, Nov 29, 2021 at 2:49 PM Michael McCandless
> <lucene@mikemccandless.com> wrote:
> >
> > Could we maybe instead bulk-add a comment explaining the split and how
> to take the PR forwards if someone (in the future) has itch/time?
> >
> > I know we humans love to clean things up, but I think leaving such
> "unclean" things open serves an important purpose. They all had importance
> to at least one person at one point in time, and likely many of them are
> still relevant if they piqued someones curiosity to dig back into them.
> Closing them makes them harder to find for the future developer.
> >
> > I'm sure some of them are already resolved/duplicates too. If only we
> could divine which are which.
> >
> >
>
> +1, I'd rather not auto-close PRs. I'm always frustrated by this when
> I see it in other trackers. Is there a rush to close these for some
> reason?
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@lucene.apache.org
> For additional commands, e-mail: dev-help@lucene.apache.org
>
>
Re: Closing GitHub PRs [ In reply to ]
In this specific instance, I don't see the harm in leaving these
issues there since the entire repo is essentially an archival artifact
at this point. If we actually want to notify people that "hey your
issue is in a dead zone, do you want to revive it? Here's how ..." we
could maybe generate some emails? Although I really have no idea how
we would accomplish that.

In general, I'm in favor of cleaning up / closing issues that are
clearly not going to be worked.

For example in JIRA we have so many old issues that they can clutter
up search results, making it much harder for new contributors
(especially) to find "interesting" issues that might be relevant today
and workable. I have heard various arguments for keeping these old
issues: they represent an historical view of the project; "you never
know" maybe they become relevant again; and this idea of not annoying
people by arbitrarily closing their issue. These all have some
validity, but I we have to strike a balance. I wonder if we can
address them in another way. In JIRA can we keep these old issues
while hiding them from default searches. Can we "archive" old issues
in some way? Maybe there is a "Status" like Archived that is different
from Closed. Anything but Open!


On Mon, Nov 29, 2021 at 4:15 PM Mike Drob <mdrob@mdrob.com> wrote:
>
> I understand the frustrations around closing somebody’s PR as stale, but I also think that there is value in informing the contributors I this is never getting solved/fixed/looked at, if this is still important please go over there instead.
>
> On Mon, Nov 29, 2021 at 1:55 PM Robert Muir <rcmuir@gmail.com> wrote:
>>
>> On Mon, Nov 29, 2021 at 2:49 PM Michael McCandless
>> <lucene@mikemccandless.com> wrote:
>> >
>> > Could we maybe instead bulk-add a comment explaining the split and how to take the PR forwards if someone (in the future) has itch/time?
>> >
>> > I know we humans love to clean things up, but I think leaving such "unclean" things open serves an important purpose. They all had importance to at least one person at one point in time, and likely many of them are still relevant if they piqued someones curiosity to dig back into them. Closing them makes them harder to find for the future developer.
>> >
>> > I'm sure some of them are already resolved/duplicates too. If only we could divine which are which.
>> >
>> >
>>
>> +1, I'd rather not auto-close PRs. I'm always frustrated by this when
>> I see it in other trackers. Is there a rush to close these for some
>> reason?
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: dev-unsubscribe@lucene.apache.org
>> For additional commands, e-mail: dev-help@lucene.apache.org
>>

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@lucene.apache.org
For additional commands, e-mail: dev-help@lucene.apache.org
Re: Closing GitHub PRs [ In reply to ]
+1 to bulk commenting on the 274 open PRs with a standard message about the need for new PRs.
We already have a "stale-closed" label in GitHub, so if we add that label to all the issues they can safely be closed without information loss.
My script https://github.com/apache/lucene/blob/main/dev-tools/scripts/githubPRs.py can probably be tweaked to do these actions. It uses a python GitHub library and already fetches all open PRs, and allows to pass a token, so I guess that the token will also allow edits on behalf of the user.

Jan

> 2. des. 2021 kl. 17:55 skrev Michael Sokolov <msokolov@gmail.com>:
>
> In this specific instance, I don't see the harm in leaving these
> issues there since the entire repo is essentially an archival artifact
> at this point. If we actually want to notify people that "hey your
> issue is in a dead zone, do you want to revive it? Here's how ..." we
> could maybe generate some emails? Although I really have no idea how
> we would accomplish that.
>
> In general, I'm in favor of cleaning up / closing issues that are
> clearly not going to be worked.
>
> For example in JIRA we have so many old issues that they can clutter
> up search results, making it much harder for new contributors
> (especially) to find "interesting" issues that might be relevant today
> and workable. I have heard various arguments for keeping these old
> issues: they represent an historical view of the project; "you never
> know" maybe they become relevant again; and this idea of not annoying
> people by arbitrarily closing their issue. These all have some
> validity, but I we have to strike a balance. I wonder if we can
> address them in another way. In JIRA can we keep these old issues
> while hiding them from default searches. Can we "archive" old issues
> in some way? Maybe there is a "Status" like Archived that is different
> from Closed. Anything but Open!
>
>
> On Mon, Nov 29, 2021 at 4:15 PM Mike Drob <mdrob@mdrob.com> wrote:
>>
>> I understand the frustrations around closing somebody’s PR as stale, but I also think that there is value in informing the contributors I this is never getting solved/fixed/looked at, if this is still important please go over there instead.
>>
>> On Mon, Nov 29, 2021 at 1:55 PM Robert Muir <rcmuir@gmail.com> wrote:
>>>
>>> On Mon, Nov 29, 2021 at 2:49 PM Michael McCandless
>>> <lucene@mikemccandless.com> wrote:
>>>>
>>>> Could we maybe instead bulk-add a comment explaining the split and how to take the PR forwards if someone (in the future) has itch/time?
>>>>
>>>> I know we humans love to clean things up, but I think leaving such "unclean" things open serves an important purpose. They all had importance to at least one person at one point in time, and likely many of them are still relevant if they piqued someones curiosity to dig back into them. Closing them makes them harder to find for the future developer.
>>>>
>>>> I'm sure some of them are already resolved/duplicates too. If only we could divine which are which.
>>>>
>>>>
>>>
>>> +1, I'd rather not auto-close PRs. I'm always frustrated by this when
>>> I see it in other trackers. Is there a rush to close these for some
>>> reason?
>>>
>>> ---------------------------------------------------------------------
>>> To unsubscribe, e-mail: dev-unsubscribe@lucene.apache.org
>>> For additional commands, e-mail: dev-help@lucene.apache.org
>>>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@lucene.apache.org
> For additional commands, e-mail: dev-help@lucene.apache.org
>


---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@lucene.apache.org
For additional commands, e-mail: dev-help@lucene.apache.org
Re: Closing GitHub PRs [ In reply to ]
I gave it a shot, and it works, so with this change to githubPRs.py script: https://github.com/apache/lucene-solr/pull/2625 we can close all open PRs with a comment and label with a single command. The script can also easily be adapted to other use cases.

Jan

> 8. des. 2021 kl. 01:33 skrev Jan Høydahl <jan.asf@cominvent.com>:
>
> +1 to bulk commenting on the 274 open PRs with a standard message about the need for new PRs.
> We already have a "stale-closed" label in GitHub, so if we add that label to all the issues they can safely be closed without information loss.
> My script https://github.com/apache/lucene/blob/main/dev-tools/scripts/githubPRs.py can probably be tweaked to do these actions. It uses a python GitHub library and already fetches all open PRs, and allows to pass a token, so I guess that the token will also allow edits on behalf of the user.
>
> Jan
>
>> 2. des. 2021 kl. 17:55 skrev Michael Sokolov <msokolov@gmail.com>:
>>
>> In this specific instance, I don't see the harm in leaving these
>> issues there since the entire repo is essentially an archival artifact
>> at this point. If we actually want to notify people that "hey your
>> issue is in a dead zone, do you want to revive it? Here's how ..." we
>> could maybe generate some emails? Although I really have no idea how
>> we would accomplish that.
>>
>> In general, I'm in favor of cleaning up / closing issues that are
>> clearly not going to be worked.
>>
>> For example in JIRA we have so many old issues that they can clutter
>> up search results, making it much harder for new contributors
>> (especially) to find "interesting" issues that might be relevant today
>> and workable. I have heard various arguments for keeping these old
>> issues: they represent an historical view of the project; "you never
>> know" maybe they become relevant again; and this idea of not annoying
>> people by arbitrarily closing their issue. These all have some
>> validity, but I we have to strike a balance. I wonder if we can
>> address them in another way. In JIRA can we keep these old issues
>> while hiding them from default searches. Can we "archive" old issues
>> in some way? Maybe there is a "Status" like Archived that is different
>> from Closed. Anything but Open!
>>
>>
>> On Mon, Nov 29, 2021 at 4:15 PM Mike Drob <mdrob@mdrob.com> wrote:
>>>
>>> I understand the frustrations around closing somebody’s PR as stale, but I also think that there is value in informing the contributors I this is never getting solved/fixed/looked at, if this is still important please go over there instead.
>>>
>>> On Mon, Nov 29, 2021 at 1:55 PM Robert Muir <rcmuir@gmail.com> wrote:
>>>>
>>>> On Mon, Nov 29, 2021 at 2:49 PM Michael McCandless
>>>> <lucene@mikemccandless.com> wrote:
>>>>>
>>>>> Could we maybe instead bulk-add a comment explaining the split and how to take the PR forwards if someone (in the future) has itch/time?
>>>>>
>>>>> I know we humans love to clean things up, but I think leaving such "unclean" things open serves an important purpose. They all had importance to at least one person at one point in time, and likely many of them are still relevant if they piqued someones curiosity to dig back into them. Closing them makes them harder to find for the future developer.
>>>>>
>>>>> I'm sure some of them are already resolved/duplicates too. If only we could divine which are which.
>>>>>
>>>>>
>>>>
>>>> +1, I'd rather not auto-close PRs. I'm always frustrated by this when
>>>> I see it in other trackers. Is there a rush to close these for some
>>>> reason?
>>>>
>>>> ---------------------------------------------------------------------
>>>> To unsubscribe, e-mail: dev-unsubscribe@lucene.apache.org
>>>> For additional commands, e-mail: dev-help@lucene.apache.org
>>>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: dev-unsubscribe@lucene.apache.org
>> For additional commands, e-mail: dev-help@lucene.apache.org
>>
>


---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@lucene.apache.org
For additional commands, e-mail: dev-help@lucene.apache.org
Re: Closing GitHub PRs [ In reply to ]
I added my vote against bulk close functionality.
it is pretty clear from this thread that several of us are opposed to
bulk close.

somehow the discussion jumped from bulk commenting to bulk close. fuck that!

On Wed, Dec 8, 2021 at 5:39 AM Jan Høydahl <jan.asf@cominvent.com> wrote:
>
> I gave it a shot, and it works, so with this change to githubPRs.py script: https://github.com/apache/lucene-solr/pull/2625 we can close all open PRs with a comment and label with a single command. The script can also easily be adapted to other use cases.
>
> Jan
>
> > 8. des. 2021 kl. 01:33 skrev Jan Høydahl <jan.asf@cominvent.com>:
> >
> > +1 to bulk commenting on the 274 open PRs with a standard message about the need for new PRs.
> > We already have a "stale-closed" label in GitHub, so if we add that label to all the issues they can safely be closed without information loss.
> > My script https://github.com/apache/lucene/blob/main/dev-tools/scripts/githubPRs.py can probably be tweaked to do these actions. It uses a python GitHub library and already fetches all open PRs, and allows to pass a token, so I guess that the token will also allow edits on behalf of the user.
> >
> > Jan
> >
> >> 2. des. 2021 kl. 17:55 skrev Michael Sokolov <msokolov@gmail.com>:
> >>
> >> In this specific instance, I don't see the harm in leaving these
> >> issues there since the entire repo is essentially an archival artifact
> >> at this point. If we actually want to notify people that "hey your
> >> issue is in a dead zone, do you want to revive it? Here's how ..." we
> >> could maybe generate some emails? Although I really have no idea how
> >> we would accomplish that.
> >>
> >> In general, I'm in favor of cleaning up / closing issues that are
> >> clearly not going to be worked.
> >>
> >> For example in JIRA we have so many old issues that they can clutter
> >> up search results, making it much harder for new contributors
> >> (especially) to find "interesting" issues that might be relevant today
> >> and workable. I have heard various arguments for keeping these old
> >> issues: they represent an historical view of the project; "you never
> >> know" maybe they become relevant again; and this idea of not annoying
> >> people by arbitrarily closing their issue. These all have some
> >> validity, but I we have to strike a balance. I wonder if we can
> >> address them in another way. In JIRA can we keep these old issues
> >> while hiding them from default searches. Can we "archive" old issues
> >> in some way? Maybe there is a "Status" like Archived that is different
> >> from Closed. Anything but Open!
> >>
> >>
> >> On Mon, Nov 29, 2021 at 4:15 PM Mike Drob <mdrob@mdrob.com> wrote:
> >>>
> >>> I understand the frustrations around closing somebody’s PR as stale, but I also think that there is value in informing the contributors I this is never getting solved/fixed/looked at, if this is still important please go over there instead.
> >>>
> >>> On Mon, Nov 29, 2021 at 1:55 PM Robert Muir <rcmuir@gmail.com> wrote:
> >>>>
> >>>> On Mon, Nov 29, 2021 at 2:49 PM Michael McCandless
> >>>> <lucene@mikemccandless.com> wrote:
> >>>>>
> >>>>> Could we maybe instead bulk-add a comment explaining the split and how to take the PR forwards if someone (in the future) has itch/time?
> >>>>>
> >>>>> I know we humans love to clean things up, but I think leaving such "unclean" things open serves an important purpose. They all had importance to at least one person at one point in time, and likely many of them are still relevant if they piqued someones curiosity to dig back into them. Closing them makes them harder to find for the future developer.
> >>>>>
> >>>>> I'm sure some of them are already resolved/duplicates too. If only we could divine which are which.
> >>>>>
> >>>>>
> >>>>
> >>>> +1, I'd rather not auto-close PRs. I'm always frustrated by this when
> >>>> I see it in other trackers. Is there a rush to close these for some
> >>>> reason?
> >>>>
> >>>> ---------------------------------------------------------------------
> >>>> To unsubscribe, e-mail: dev-unsubscribe@lucene.apache.org
> >>>> For additional commands, e-mail: dev-help@lucene.apache.org
> >>>>
> >>
> >> ---------------------------------------------------------------------
> >> To unsubscribe, e-mail: dev-unsubscribe@lucene.apache.org
> >> For additional commands, e-mail: dev-help@lucene.apache.org
> >>
> >
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@lucene.apache.org
> For additional commands, e-mail: dev-help@lucene.apache.org
>

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@lucene.apache.org
For additional commands, e-mail: dev-help@lucene.apache.org
Re: Closing GitHub PRs [ In reply to ]
On Wed, Dec 8, 2021 at 7:01 AM Robert Muir <rcmuir@gmail.com> wrote:
>
> I added my vote against bulk close functionality.
> it is pretty clear from this thread that several of us are opposed to
> bulk close.
>
> somehow the discussion jumped from bulk commenting to bulk close. fuck that!
>
> On Wed, Dec 8, 2021 at 5:39 AM Jan Høydahl <jan.asf@cominvent.com> wrote:
> >
> > I gave it a shot, and it works, so with this change to githubPRs.py script: https://github.com/apache/lucene-solr/pull/2625 we can close all open PRs with a comment and label with a single command. The script can also easily be adapted to other use cases.
> >
> > Jan
> >
> > > 8. des. 2021 kl. 01:33 skrev Jan Høydahl <jan.asf@cominvent.com>:
> > >
> > > +1 to bulk commenting on the 274 open PRs with a standard message about the need for new PRs.
> > > We already have a "stale-closed" label in GitHub, so if we add that label to all the issues they can safely be closed without information loss.
> > > My script https://github.com/apache/lucene/blob/main/dev-tools/scripts/githubPRs.py can probably be tweaked to do these actions. It uses a python GitHub library and already fetches all open PRs, and allows to pass a token, so I guess that the token will also allow edits on behalf of the user.
> > >
> > > Jan
> > >
> > >> 2. des. 2021 kl. 17:55 skrev Michael Sokolov <msokolov@gmail.com>:
> > >>
> > >> In this specific instance, I don't see the harm in leaving these
> > >> issues there since the entire repo is essentially an archival artifact
> > >> at this point. If we actually want to notify people that "hey your
> > >> issue is in a dead zone, do you want to revive it? Here's how ..." we
> > >> could maybe generate some emails? Although I really have no idea how
> > >> we would accomplish that.
> > >>
> > >> In general, I'm in favor of cleaning up / closing issues that are
> > >> clearly not going to be worked.
> > >>
> > >> For example in JIRA we have so many old issues that they can clutter
> > >> up search results, making it much harder for new contributors
> > >> (especially) to find "interesting" issues that might be relevant today
> > >> and workable. I have heard various arguments for keeping these old
> > >> issues: they represent an historical view of the project; "you never
> > >> know" maybe they become relevant again; and this idea of not annoying
> > >> people by arbitrarily closing their issue. These all have some
> > >> validity, but I we have to strike a balance. I wonder if we can
> > >> address them in another way. In JIRA can we keep these old issues
> > >> while hiding them from default searches. Can we "archive" old issues
> > >> in some way? Maybe there is a "Status" like Archived that is different
> > >> from Closed. Anything but Open!
> > >>
> > >>
> > >> On Mon, Nov 29, 2021 at 4:15 PM Mike Drob <mdrob@mdrob.com> wrote:
> > >>>
> > >>> I understand the frustrations around closing somebody’s PR as stale, but I also think that there is value in informing the contributors I this is never getting solved/fixed/looked at, if this is still important please go over there instead.
> > >>>
> > >>> On Mon, Nov 29, 2021 at 1:55 PM Robert Muir <rcmuir@gmail.com> wrote:
> > >>>>
> > >>>> On Mon, Nov 29, 2021 at 2:49 PM Michael McCandless
> > >>>> <lucene@mikemccandless.com> wrote:
> > >>>>>
> > >>>>> Could we maybe instead bulk-add a comment explaining the split and how to take the PR forwards if someone (in the future) has itch/time?
> > >>>>>
> > >>>>> I know we humans love to clean things up, but I think leaving such "unclean" things open serves an important purpose. They all had importance to at least one person at one point in time, and likely many of them are still relevant if they piqued someones curiosity to dig back into them. Closing them makes them harder to find for the future developer.
> > >>>>>
> > >>>>> I'm sure some of them are already resolved/duplicates too. If only we could divine which are which.
> > >>>>>
> > >>>>>
> > >>>>
> > >>>> +1, I'd rather not auto-close PRs. I'm always frustrated by this when
> > >>>> I see it in other trackers. Is there a rush to close these for some
> > >>>> reason?
> > >>>>
> > >>>> ---------------------------------------------------------------------
> > >>>> To unsubscribe, e-mail: dev-unsubscribe@lucene.apache.org
> > >>>> For additional commands, e-mail: dev-help@lucene.apache.org
> > >>>>
> > >>
> > >> ---------------------------------------------------------------------
> > >> To unsubscribe, e-mail: dev-unsubscribe@lucene.apache.org
> > >> For additional commands, e-mail: dev-help@lucene.apache.org
> > >>
> > >
> >
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: dev-unsubscribe@lucene.apache.org
> > For additional commands, e-mail: dev-help@lucene.apache.org
> >

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@lucene.apache.org
For additional commands, e-mail: dev-help@lucene.apache.org
Re: Closing GitHub PRs [ In reply to ]
i mean you dont even have anything close to fucking consensus about
"bulk close" on this thread. most are against it. why be so fucking
sneaky about it? I don't get it!

On Wed, Dec 8, 2021 at 7:03 AM Robert Muir <rcmuir@gmail.com> wrote:
>
> On Wed, Dec 8, 2021 at 7:01 AM Robert Muir <rcmuir@gmail.com> wrote:
> >
> > I added my vote against bulk close functionality.
> > it is pretty clear from this thread that several of us are opposed to
> > bulk close.
> >
> > somehow the discussion jumped from bulk commenting to bulk close. fuck that!
> >
> > On Wed, Dec 8, 2021 at 5:39 AM Jan Høydahl <jan.asf@cominvent.com> wrote:
> > >
> > > I gave it a shot, and it works, so with this change to githubPRs.py script: https://github.com/apache/lucene-solr/pull/2625 we can close all open PRs with a comment and label with a single command. The script can also easily be adapted to other use cases.
> > >
> > > Jan
> > >
> > > > 8. des. 2021 kl. 01:33 skrev Jan Høydahl <jan.asf@cominvent.com>:
> > > >
> > > > +1 to bulk commenting on the 274 open PRs with a standard message about the need for new PRs.
> > > > We already have a "stale-closed" label in GitHub, so if we add that label to all the issues they can safely be closed without information loss.
> > > > My script https://github.com/apache/lucene/blob/main/dev-tools/scripts/githubPRs.py can probably be tweaked to do these actions. It uses a python GitHub library and already fetches all open PRs, and allows to pass a token, so I guess that the token will also allow edits on behalf of the user.
> > > >
> > > > Jan
> > > >
> > > >> 2. des. 2021 kl. 17:55 skrev Michael Sokolov <msokolov@gmail.com>:
> > > >>
> > > >> In this specific instance, I don't see the harm in leaving these
> > > >> issues there since the entire repo is essentially an archival artifact
> > > >> at this point. If we actually want to notify people that "hey your
> > > >> issue is in a dead zone, do you want to revive it? Here's how ..." we
> > > >> could maybe generate some emails? Although I really have no idea how
> > > >> we would accomplish that.
> > > >>
> > > >> In general, I'm in favor of cleaning up / closing issues that are
> > > >> clearly not going to be worked.
> > > >>
> > > >> For example in JIRA we have so many old issues that they can clutter
> > > >> up search results, making it much harder for new contributors
> > > >> (especially) to find "interesting" issues that might be relevant today
> > > >> and workable. I have heard various arguments for keeping these old
> > > >> issues: they represent an historical view of the project; "you never
> > > >> know" maybe they become relevant again; and this idea of not annoying
> > > >> people by arbitrarily closing their issue. These all have some
> > > >> validity, but I we have to strike a balance. I wonder if we can
> > > >> address them in another way. In JIRA can we keep these old issues
> > > >> while hiding them from default searches. Can we "archive" old issues
> > > >> in some way? Maybe there is a "Status" like Archived that is different
> > > >> from Closed. Anything but Open!
> > > >>
> > > >>
> > > >> On Mon, Nov 29, 2021 at 4:15 PM Mike Drob <mdrob@mdrob.com> wrote:
> > > >>>
> > > >>> I understand the frustrations around closing somebody’s PR as stale, but I also think that there is value in informing the contributors I this is never getting solved/fixed/looked at, if this is still important please go over there instead.
> > > >>>
> > > >>> On Mon, Nov 29, 2021 at 1:55 PM Robert Muir <rcmuir@gmail.com> wrote:
> > > >>>>
> > > >>>> On Mon, Nov 29, 2021 at 2:49 PM Michael McCandless
> > > >>>> <lucene@mikemccandless.com> wrote:
> > > >>>>>
> > > >>>>> Could we maybe instead bulk-add a comment explaining the split and how to take the PR forwards if someone (in the future) has itch/time?
> > > >>>>>
> > > >>>>> I know we humans love to clean things up, but I think leaving such "unclean" things open serves an important purpose. They all had importance to at least one person at one point in time, and likely many of them are still relevant if they piqued someones curiosity to dig back into them. Closing them makes them harder to find for the future developer.
> > > >>>>>
> > > >>>>> I'm sure some of them are already resolved/duplicates too. If only we could divine which are which.
> > > >>>>>
> > > >>>>>
> > > >>>>
> > > >>>> +1, I'd rather not auto-close PRs. I'm always frustrated by this when
> > > >>>> I see it in other trackers. Is there a rush to close these for some
> > > >>>> reason?
> > > >>>>
> > > >>>> ---------------------------------------------------------------------
> > > >>>> To unsubscribe, e-mail: dev-unsubscribe@lucene.apache.org
> > > >>>> For additional commands, e-mail: dev-help@lucene.apache.org
> > > >>>>
> > > >>
> > > >> ---------------------------------------------------------------------
> > > >> To unsubscribe, e-mail: dev-unsubscribe@lucene.apache.org
> > > >> For additional commands, e-mail: dev-help@lucene.apache.org
> > > >>
> > > >
> > >
> > >
> > > ---------------------------------------------------------------------
> > > To unsubscribe, e-mail: dev-unsubscribe@lucene.apache.org
> > > For additional commands, e-mail: dev-help@lucene.apache.org
> > >

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@lucene.apache.org
For additional commands, e-mail: dev-help@lucene.apache.org
Re: Closing GitHub PRs [ In reply to ]
Calm down :)

As you can read from the last comment, we can choose whether to
* Close with comment and label
* Comment and label only
* Comment only
* Do nothing

The lucene-solr repo is not dead, it will still be used for back-porting bugfixes to branch_8_11 for probably another 12 months.
Byt several branches are dead/archived, and it really makes no sense to keep PRs for those alive either.

This is a proposal for a one-time action, introducing a stale-bot for the project, which I can see is more controversial and annoying for sure.

Jan

> 8. des. 2021 kl. 13:04 skrev Robert Muir <rcmuir@gmail.com>:
>
> i mean you dont even have anything close to fucking consensus about
> "bulk close" on this thread. most are against it. why be so fucking
> sneaky about it? I don't get it!
>
> On Wed, Dec 8, 2021 at 7:03 AM Robert Muir <rcmuir@gmail.com> wrote:
>>
>> On Wed, Dec 8, 2021 at 7:01 AM Robert Muir <rcmuir@gmail.com> wrote:
>>>
>>> I added my vote against bulk close functionality.
>>> it is pretty clear from this thread that several of us are opposed to
>>> bulk close.
>>>
>>> somehow the discussion jumped from bulk commenting to bulk close. fuck that!
>>>
>>> On Wed, Dec 8, 2021 at 5:39 AM Jan Høydahl <jan.asf@cominvent.com> wrote:
>>>>
>>>> I gave it a shot, and it works, so with this change to githubPRs.py script: https://github.com/apache/lucene-solr/pull/2625 we can close all open PRs with a comment and label with a single command. The script can also easily be adapted to other use cases.
>>>>
>>>> Jan
>>>>
>>>>> 8. des. 2021 kl. 01:33 skrev Jan Høydahl <jan.asf@cominvent.com>:
>>>>>
>>>>> +1 to bulk commenting on the 274 open PRs with a standard message about the need for new PRs.
>>>>> We already have a "stale-closed" label in GitHub, so if we add that label to all the issues they can safely be closed without information loss.
>>>>> My script https://github.com/apache/lucene/blob/main/dev-tools/scripts/githubPRs.py can probably be tweaked to do these actions. It uses a python GitHub library and already fetches all open PRs, and allows to pass a token, so I guess that the token will also allow edits on behalf of the user.
>>>>>
>>>>> Jan
>>>>>
>>>>>> 2. des. 2021 kl. 17:55 skrev Michael Sokolov <msokolov@gmail.com>:
>>>>>>
>>>>>> In this specific instance, I don't see the harm in leaving these
>>>>>> issues there since the entire repo is essentially an archival artifact
>>>>>> at this point. If we actually want to notify people that "hey your
>>>>>> issue is in a dead zone, do you want to revive it? Here's how ..." we
>>>>>> could maybe generate some emails? Although I really have no idea how
>>>>>> we would accomplish that.
>>>>>>
>>>>>> In general, I'm in favor of cleaning up / closing issues that are
>>>>>> clearly not going to be worked.
>>>>>>
>>>>>> For example in JIRA we have so many old issues that they can clutter
>>>>>> up search results, making it much harder for new contributors
>>>>>> (especially) to find "interesting" issues that might be relevant today
>>>>>> and workable. I have heard various arguments for keeping these old
>>>>>> issues: they represent an historical view of the project; "you never
>>>>>> know" maybe they become relevant again; and this idea of not annoying
>>>>>> people by arbitrarily closing their issue. These all have some
>>>>>> validity, but I we have to strike a balance. I wonder if we can
>>>>>> address them in another way. In JIRA can we keep these old issues
>>>>>> while hiding them from default searches. Can we "archive" old issues
>>>>>> in some way? Maybe there is a "Status" like Archived that is different
>>>>>> from Closed. Anything but Open!
>>>>>>
>>>>>>
>>>>>> On Mon, Nov 29, 2021 at 4:15 PM Mike Drob <mdrob@mdrob.com> wrote:
>>>>>>>
>>>>>>> I understand the frustrations around closing somebody’s PR as stale, but I also think that there is value in informing the contributors I this is never getting solved/fixed/looked at, if this is still important please go over there instead.
>>>>>>>
>>>>>>> On Mon, Nov 29, 2021 at 1:55 PM Robert Muir <rcmuir@gmail.com> wrote:
>>>>>>>>
>>>>>>>> On Mon, Nov 29, 2021 at 2:49 PM Michael McCandless
>>>>>>>> <lucene@mikemccandless.com> wrote:
>>>>>>>>>
>>>>>>>>> Could we maybe instead bulk-add a comment explaining the split and how to take the PR forwards if someone (in the future) has itch/time?
>>>>>>>>>
>>>>>>>>> I know we humans love to clean things up, but I think leaving such "unclean" things open serves an important purpose. They all had importance to at least one person at one point in time, and likely many of them are still relevant if they piqued someones curiosity to dig back into them. Closing them makes them harder to find for the future developer.
>>>>>>>>>
>>>>>>>>> I'm sure some of them are already resolved/duplicates too. If only we could divine which are which.
>>>>>>>>>
>>>>>>>>>
>>>>>>>>
>>>>>>>> +1, I'd rather not auto-close PRs. I'm always frustrated by this when
>>>>>>>> I see it in other trackers. Is there a rush to close these for some
>>>>>>>> reason?
>>>>>>>>
>>>>>>>> ---------------------------------------------------------------------
>>>>>>>> To unsubscribe, e-mail: dev-unsubscribe@lucene.apache.org
>>>>>>>> For additional commands, e-mail: dev-help@lucene.apache.org
>>>>>>>>
>>>>>>
>>>>>> ---------------------------------------------------------------------
>>>>>> To unsubscribe, e-mail: dev-unsubscribe@lucene.apache.org
>>>>>> For additional commands, e-mail: dev-help@lucene.apache.org
>>>>>>
>>>>>
>>>>
>>>>
>>>> ---------------------------------------------------------------------
>>>> To unsubscribe, e-mail: dev-unsubscribe@lucene.apache.org
>>>> For additional commands, e-mail: dev-help@lucene.apache.org
>>>>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@lucene.apache.org
> For additional commands, e-mail: dev-help@lucene.apache.org
>


---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@lucene.apache.org
For additional commands, e-mail: dev-help@lucene.apache.org
Re: Closing GitHub PRs [ In reply to ]
> This is a proposal for a one-time action, introducing a stale-bot for the project, which I can see is more controversial and annoying for sure.

Correction: This is a proposal for a one-time action, NOT introducing a stale-bot for the project, which I can see is more controversial and annoying for sure.


---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@lucene.apache.org
For additional commands, e-mail: dev-help@lucene.apache.org
Re: Closing GitHub PRs [ In reply to ]
The same script githubPRs.py also tells us which PRs are linked to an already closed JIRA, which are clear candidates for closing

Open PRs with a resolved JIRA
#182: SOLR-10415 status=Closed, resolution=Fixed, resolutiondate=2020-05-01T17:19:28.000+0000 (SOLR-10415 - improve debug logging to use parameterized logging)
#185: SOLR-10487 status=Resolved, resolution=Won't Fix, resolutiondate=2020-08-29T20:04:17.000+0000 (SOLR-10487: Support to specify connection and socket read timeout in DataImportHandler for SolrEntityProcessor.)
#210: SOLR-10814 status=Resolved, resolution=Fixed, resolutiondate=2020-07-08T15:27:13.000+0000 ([SOLR-10814] Solr RuleBasedAuthorizationPlugin works seamlessly with …)
#690: SOLR-13517 status=Resolved, resolution=Duplicate, resolutiondate=2021-08-18T21:34:14.000+0000 (SOLR-13517: [ UX improvement ] Dashboard will now store query and filter parameters on page change a…)
#740: SOLR-12550 status=Closed, resolution=Fixed, resolutiondate=2020-02-20T12:57:57.000+0000 (SOLR-12550 - distribUpdateSoTimeout for configuring socket timeouts in solrcloud doesn't take effect for updates.)
#864: SOLR-13101 status=Resolved, resolution=Won't Fix, resolutiondate=2020-12-11T03:20:31.000+0000 (SOLR-13101 : Shared storage support in SolrCloud)
#888: SOLR-13774 status=Resolved, resolution=Won't Fix, resolutiondate=2020-03-30T01:15:59.000+0000 (SOLR-13774 add lucene/solr openjdk compatibility matrix to ref guide.)
#906: LUCENE-8996 status=Closed, resolution=Fixed, resolutiondate=2019-12-09T14:59:16.000+0000 (LUCENE-8996: maxScore is sometimes missing from distributed responses)
#1060: SOLR-14024 status=Resolved, resolution=Fixed, resolutiondate=2021-03-24T18:25:12.000+0000 (SOLR-14024: Invalid html generated by changes2html.pl)
#1064: LUCENE-9084 status=Closed, resolution=Fixed, resolutiondate=2020-01-09T00:45:51.000+0000 (LUCENE-9084: circular synchronization wait (potential deadlock) in AnalyzingInfixSuggester)
#1079: SOLR-14067 status=Resolved, resolution=Fixed, resolutiondate=2021-02-04T16:32:52.000+0000 (SOLR-14067: StatelessScriptUpdateProcessor removal due to security concerns)
#1144: SOLR-13756 status=Closed, resolution=Not A Problem, resolutiondate=2021-01-18T12:36:38.000+0000 (SOLR-13756 updated restlet mvn repository url.)
#1175: SOLR-13749 status=Closed, resolution=Fixed, resolutiondate=2020-06-25T16:57:48.000+0000 (Backport SOLR-13749 Cross-collection join filter to 8.x)
#1231: SOLR-13132 status=Closed, resolution=Fixed, resolutiondate=2020-07-10T04:06:30.000+0000 (SOLR-13132: single sweep iteration over base, foreground, and backgro…)
#1383: SOLR-14367 status=Closed, resolution=Fixed, resolutiondate=2020-03-29T13:41:12.000+0000 (SOLR-14367: Updated Tika version to 1.24)
#1386: SOLR-14275 status=Resolved, resolution=Won't Fix, resolutiondate=2020-11-11T12:50:52.000+0000 (SOLR-14275 Policy calculations are very slow for large clusters and large operations)
#1622: SOLR-14603 status=Closed, resolution=Fixed, resolutiondate=2020-07-04T11:59:17.000+0000 (SOLR-14603: update Restlet version )
#1721: LUCENE-9439 status=Resolved, resolution=Duplicate, resolutiondate=2020-08-14T09:05:58.000+0000 (LUCENE-9439: match region highlighter components)
#1744: SOLR-14731 status=Closed, resolution=Fixed, resolutiondate=2020-08-18T10:55:48.000+0000 (SOLR-14731: Add SingleThreaded Annotation to Class)
#1768: LUCENE-9472 status=Resolved, resolution=Workaround, resolutiondate=2020-08-20T15:13:48.000+0000 (LUCENE-9472: Test duplication within gradle's infrastructure.)
#1784: LUCENE-9482 status=Closed, resolution=Fixed, resolutiondate=2020-09-06T15:16:45.000+0000 (LUCENE-9482: There is a problem with the description of "invalid deletion count" exception.)
#1827: SOLR-14792 status=Resolved, resolution=Fixed, resolutiondate=2021-02-15T18:22:53.000+0000 (SOLR-14792: Remove VelocityResponseWriter)
#1923: SOLR-14900 status=Resolved, resolution=Fixed, resolutiondate=2021-07-21T18:43:01.000+0000 (SOLR-14900: Reference Guide build cleanup/module upgrade)
#1957: SOLR-14918 status=Resolved, resolution=Won't Fix, resolutiondate=2020-10-13T19:08:35.000+0000 (SOLR-14918 add "failIfEmptyCores" param for healthcheck handler)
#2080: LUCENE-8947 status=Resolved, resolution=Won't Fix, resolutiondate=2021-01-16T12:14:35.000+0000 (LUCENE-8947: Skip field length accumulation when norms are disabled)
#2100: LUCENE-9047 status=Resolved, resolution=Fixed, resolutiondate=2021-05-03T05:50:21.000+0000 (LUCENE-9047: PoC of some ideas regarding transparent, efficient handling of byte order )
#2244: SOLR-15099 status=Resolved, resolution=Won't Fix, resolutiondate=2021-08-14T01:41:33.000+0000 (SOLR-15099 Add null checks to IndexSizeTrigger)
#2252: SOLR-15111 status=Resolved, resolution=Fixed, resolutiondate=2021-08-31T14:03:53.000+0000 (SOLR-15111: Use JDK8 Base64 instead of own implementation)
#2415: SOLR-15178 status=Resolved, resolution=Fixed, resolutiondate=2021-03-19T07:21:16.000+0000 (SOLR-15178 Non-existent dependency listed in solr-core)

Jan

> 8. des. 2021 kl. 13:55 skrev Jan Høydahl <jan.asf@cominvent.com>:
>
>> This is a proposal for a one-time action, introducing a stale-bot for the project, which I can see is more controversial and annoying for sure.
>
> Correction: This is a proposal for a one-time action, NOT introducing a stale-bot for the project, which I can see is more controversial and annoying for sure.
>


---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@lucene.apache.org
For additional commands, e-mail: dev-help@lucene.apache.org
Re: Closing GitHub PRs [ In reply to ]
I'm -1 against auto-closing issues, as I already stated on this thread.

On Wed, Dec 8, 2021 at 7:53 AM Jan Høydahl <jan.asf@cominvent.com> wrote:
>
> Calm down :)
>
> As you can read from the last comment, we can choose whether to
> * Close with comment and label
> * Comment and label only
> * Comment only
> * Do nothing
>
> The lucene-solr repo is not dead, it will still be used for back-porting bugfixes to branch_8_11 for probably another 12 months.
> Byt several branches are dead/archived, and it really makes no sense to keep PRs for those alive either.
>
> This is a proposal for a one-time action, introducing a stale-bot for the project, which I can see is more controversial and annoying for sure.
>
> Jan
>
> > 8. des. 2021 kl. 13:04 skrev Robert Muir <rcmuir@gmail.com>:
> >
> > i mean you dont even have anything close to fucking consensus about
> > "bulk close" on this thread. most are against it. why be so fucking
> > sneaky about it? I don't get it!
> >
> > On Wed, Dec 8, 2021 at 7:03 AM Robert Muir <rcmuir@gmail.com> wrote:
> >>
> >> On Wed, Dec 8, 2021 at 7:01 AM Robert Muir <rcmuir@gmail.com> wrote:
> >>>
> >>> I added my vote against bulk close functionality.
> >>> it is pretty clear from this thread that several of us are opposed to
> >>> bulk close.
> >>>
> >>> somehow the discussion jumped from bulk commenting to bulk close. fuck that!
> >>>
> >>> On Wed, Dec 8, 2021 at 5:39 AM Jan Høydahl <jan.asf@cominvent.com> wrote:
> >>>>
> >>>> I gave it a shot, and it works, so with this change to githubPRs.py script: https://github.com/apache/lucene-solr/pull/2625 we can close all open PRs with a comment and label with a single command. The script can also easily be adapted to other use cases.
> >>>>
> >>>> Jan
> >>>>
> >>>>> 8. des. 2021 kl. 01:33 skrev Jan Høydahl <jan.asf@cominvent.com>:
> >>>>>
> >>>>> +1 to bulk commenting on the 274 open PRs with a standard message about the need for new PRs.
> >>>>> We already have a "stale-closed" label in GitHub, so if we add that label to all the issues they can safely be closed without information loss.
> >>>>> My script https://github.com/apache/lucene/blob/main/dev-tools/scripts/githubPRs.py can probably be tweaked to do these actions. It uses a python GitHub library and already fetches all open PRs, and allows to pass a token, so I guess that the token will also allow edits on behalf of the user.
> >>>>>
> >>>>> Jan
> >>>>>
> >>>>>> 2. des. 2021 kl. 17:55 skrev Michael Sokolov <msokolov@gmail.com>:
> >>>>>>
> >>>>>> In this specific instance, I don't see the harm in leaving these
> >>>>>> issues there since the entire repo is essentially an archival artifact
> >>>>>> at this point. If we actually want to notify people that "hey your
> >>>>>> issue is in a dead zone, do you want to revive it? Here's how ..." we
> >>>>>> could maybe generate some emails? Although I really have no idea how
> >>>>>> we would accomplish that.
> >>>>>>
> >>>>>> In general, I'm in favor of cleaning up / closing issues that are
> >>>>>> clearly not going to be worked.
> >>>>>>
> >>>>>> For example in JIRA we have so many old issues that they can clutter
> >>>>>> up search results, making it much harder for new contributors
> >>>>>> (especially) to find "interesting" issues that might be relevant today
> >>>>>> and workable. I have heard various arguments for keeping these old
> >>>>>> issues: they represent an historical view of the project; "you never
> >>>>>> know" maybe they become relevant again; and this idea of not annoying
> >>>>>> people by arbitrarily closing their issue. These all have some
> >>>>>> validity, but I we have to strike a balance. I wonder if we can
> >>>>>> address them in another way. In JIRA can we keep these old issues
> >>>>>> while hiding them from default searches. Can we "archive" old issues
> >>>>>> in some way? Maybe there is a "Status" like Archived that is different
> >>>>>> from Closed. Anything but Open!
> >>>>>>
> >>>>>>
> >>>>>> On Mon, Nov 29, 2021 at 4:15 PM Mike Drob <mdrob@mdrob.com> wrote:
> >>>>>>>
> >>>>>>> I understand the frustrations around closing somebody’s PR as stale, but I also think that there is value in informing the contributors I this is never getting solved/fixed/looked at, if this is still important please go over there instead.
> >>>>>>>
> >>>>>>> On Mon, Nov 29, 2021 at 1:55 PM Robert Muir <rcmuir@gmail.com> wrote:
> >>>>>>>>
> >>>>>>>> On Mon, Nov 29, 2021 at 2:49 PM Michael McCandless
> >>>>>>>> <lucene@mikemccandless.com> wrote:
> >>>>>>>>>
> >>>>>>>>> Could we maybe instead bulk-add a comment explaining the split and how to take the PR forwards if someone (in the future) has itch/time?
> >>>>>>>>>
> >>>>>>>>> I know we humans love to clean things up, but I think leaving such "unclean" things open serves an important purpose. They all had importance to at least one person at one point in time, and likely many of them are still relevant if they piqued someones curiosity to dig back into them. Closing them makes them harder to find for the future developer.
> >>>>>>>>>
> >>>>>>>>> I'm sure some of them are already resolved/duplicates too. If only we could divine which are which.
> >>>>>>>>>
> >>>>>>>>>
> >>>>>>>>
> >>>>>>>> +1, I'd rather not auto-close PRs. I'm always frustrated by this when
> >>>>>>>> I see it in other trackers. Is there a rush to close these for some
> >>>>>>>> reason?
> >>>>>>>>
> >>>>>>>> ---------------------------------------------------------------------
> >>>>>>>> To unsubscribe, e-mail: dev-unsubscribe@lucene.apache.org
> >>>>>>>> For additional commands, e-mail: dev-help@lucene.apache.org
> >>>>>>>>
> >>>>>>
> >>>>>> ---------------------------------------------------------------------
> >>>>>> To unsubscribe, e-mail: dev-unsubscribe@lucene.apache.org
> >>>>>> For additional commands, e-mail: dev-help@lucene.apache.org
> >>>>>>
> >>>>>
> >>>>
> >>>>
> >>>> ---------------------------------------------------------------------
> >>>> To unsubscribe, e-mail: dev-unsubscribe@lucene.apache.org
> >>>> For additional commands, e-mail: dev-help@lucene.apache.org
> >>>>
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: dev-unsubscribe@lucene.apache.org
> > For additional commands, e-mail: dev-help@lucene.apache.org
> >
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@lucene.apache.org
> For additional commands, e-mail: dev-help@lucene.apache.org
>

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@lucene.apache.org
For additional commands, e-mail: dev-help@lucene.apache.org
Re: Closing GitHub PRs [ In reply to ]
I'm also now even -1 against bulk-comment. You guys are trying to be
too sneaky/passive-aggressive/bypass consensus. I'm stopping this shit
right now in its tracks

On Wed, Dec 8, 2021 at 8:50 AM Robert Muir <rcmuir@gmail.com> wrote:
>
> I'm -1 against auto-closing issues, as I already stated on this thread.
>
> On Wed, Dec 8, 2021 at 7:53 AM Jan Høydahl <jan.asf@cominvent.com> wrote:
> >
> > Calm down :)
> >
> > As you can read from the last comment, we can choose whether to
> > * Close with comment and label
> > * Comment and label only
> > * Comment only
> > * Do nothing
> >
> > The lucene-solr repo is not dead, it will still be used for back-porting bugfixes to branch_8_11 for probably another 12 months.
> > Byt several branches are dead/archived, and it really makes no sense to keep PRs for those alive either.
> >
> > This is a proposal for a one-time action, introducing a stale-bot for the project, which I can see is more controversial and annoying for sure.
> >
> > Jan
> >
> > > 8. des. 2021 kl. 13:04 skrev Robert Muir <rcmuir@gmail.com>:
> > >
> > > i mean you dont even have anything close to fucking consensus about
> > > "bulk close" on this thread. most are against it. why be so fucking
> > > sneaky about it? I don't get it!
> > >
> > > On Wed, Dec 8, 2021 at 7:03 AM Robert Muir <rcmuir@gmail.com> wrote:
> > >>
> > >> On Wed, Dec 8, 2021 at 7:01 AM Robert Muir <rcmuir@gmail.com> wrote:
> > >>>
> > >>> I added my vote against bulk close functionality.
> > >>> it is pretty clear from this thread that several of us are opposed to
> > >>> bulk close.
> > >>>
> > >>> somehow the discussion jumped from bulk commenting to bulk close. fuck that!
> > >>>
> > >>> On Wed, Dec 8, 2021 at 5:39 AM Jan Høydahl <jan.asf@cominvent.com> wrote:
> > >>>>
> > >>>> I gave it a shot, and it works, so with this change to githubPRs.py script: https://github.com/apache/lucene-solr/pull/2625 we can close all open PRs with a comment and label with a single command. The script can also easily be adapted to other use cases.
> > >>>>
> > >>>> Jan
> > >>>>
> > >>>>> 8. des. 2021 kl. 01:33 skrev Jan Høydahl <jan.asf@cominvent.com>:
> > >>>>>
> > >>>>> +1 to bulk commenting on the 274 open PRs with a standard message about the need for new PRs.
> > >>>>> We already have a "stale-closed" label in GitHub, so if we add that label to all the issues they can safely be closed without information loss.
> > >>>>> My script https://github.com/apache/lucene/blob/main/dev-tools/scripts/githubPRs.py can probably be tweaked to do these actions. It uses a python GitHub library and already fetches all open PRs, and allows to pass a token, so I guess that the token will also allow edits on behalf of the user.
> > >>>>>
> > >>>>> Jan
> > >>>>>
> > >>>>>> 2. des. 2021 kl. 17:55 skrev Michael Sokolov <msokolov@gmail.com>:
> > >>>>>>
> > >>>>>> In this specific instance, I don't see the harm in leaving these
> > >>>>>> issues there since the entire repo is essentially an archival artifact
> > >>>>>> at this point. If we actually want to notify people that "hey your
> > >>>>>> issue is in a dead zone, do you want to revive it? Here's how ..." we
> > >>>>>> could maybe generate some emails? Although I really have no idea how
> > >>>>>> we would accomplish that.
> > >>>>>>
> > >>>>>> In general, I'm in favor of cleaning up / closing issues that are
> > >>>>>> clearly not going to be worked.
> > >>>>>>
> > >>>>>> For example in JIRA we have so many old issues that they can clutter
> > >>>>>> up search results, making it much harder for new contributors
> > >>>>>> (especially) to find "interesting" issues that might be relevant today
> > >>>>>> and workable. I have heard various arguments for keeping these old
> > >>>>>> issues: they represent an historical view of the project; "you never
> > >>>>>> know" maybe they become relevant again; and this idea of not annoying
> > >>>>>> people by arbitrarily closing their issue. These all have some
> > >>>>>> validity, but I we have to strike a balance. I wonder if we can
> > >>>>>> address them in another way. In JIRA can we keep these old issues
> > >>>>>> while hiding them from default searches. Can we "archive" old issues
> > >>>>>> in some way? Maybe there is a "Status" like Archived that is different
> > >>>>>> from Closed. Anything but Open!
> > >>>>>>
> > >>>>>>
> > >>>>>> On Mon, Nov 29, 2021 at 4:15 PM Mike Drob <mdrob@mdrob.com> wrote:
> > >>>>>>>
> > >>>>>>> I understand the frustrations around closing somebody’s PR as stale, but I also think that there is value in informing the contributors I this is never getting solved/fixed/looked at, if this is still important please go over there instead.
> > >>>>>>>
> > >>>>>>> On Mon, Nov 29, 2021 at 1:55 PM Robert Muir <rcmuir@gmail.com> wrote:
> > >>>>>>>>
> > >>>>>>>> On Mon, Nov 29, 2021 at 2:49 PM Michael McCandless
> > >>>>>>>> <lucene@mikemccandless.com> wrote:
> > >>>>>>>>>
> > >>>>>>>>> Could we maybe instead bulk-add a comment explaining the split and how to take the PR forwards if someone (in the future) has itch/time?
> > >>>>>>>>>
> > >>>>>>>>> I know we humans love to clean things up, but I think leaving such "unclean" things open serves an important purpose. They all had importance to at least one person at one point in time, and likely many of them are still relevant if they piqued someones curiosity to dig back into them. Closing them makes them harder to find for the future developer.
> > >>>>>>>>>
> > >>>>>>>>> I'm sure some of them are already resolved/duplicates too. If only we could divine which are which.
> > >>>>>>>>>
> > >>>>>>>>>
> > >>>>>>>>
> > >>>>>>>> +1, I'd rather not auto-close PRs. I'm always frustrated by this when
> > >>>>>>>> I see it in other trackers. Is there a rush to close these for some
> > >>>>>>>> reason?
> > >>>>>>>>
> > >>>>>>>> ---------------------------------------------------------------------
> > >>>>>>>> To unsubscribe, e-mail: dev-unsubscribe@lucene.apache.org
> > >>>>>>>> For additional commands, e-mail: dev-help@lucene.apache.org
> > >>>>>>>>
> > >>>>>>
> > >>>>>> ---------------------------------------------------------------------
> > >>>>>> To unsubscribe, e-mail: dev-unsubscribe@lucene.apache.org
> > >>>>>> For additional commands, e-mail: dev-help@lucene.apache.org
> > >>>>>>
> > >>>>>
> > >>>>
> > >>>>
> > >>>> ---------------------------------------------------------------------
> > >>>> To unsubscribe, e-mail: dev-unsubscribe@lucene.apache.org
> > >>>> For additional commands, e-mail: dev-help@lucene.apache.org
> > >>>>
> > >
> > > ---------------------------------------------------------------------
> > > To unsubscribe, e-mail: dev-unsubscribe@lucene.apache.org
> > > For additional commands, e-mail: dev-help@lucene.apache.org
> > >
> >
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: dev-unsubscribe@lucene.apache.org
> > For additional commands, e-mail: dev-help@lucene.apache.org
> >

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@lucene.apache.org
For additional commands, e-mail: dev-help@lucene.apache.org
Re: Closing GitHub PRs [ In reply to ]
I think the script is already proving helpful, finding PRs whose
corresponding issues were closed. I guess it is possible that some of
those PRs might still be relevant, but likely most of them should be
closed? This seems helpful. I spot checked a couple of these. One of
them indeed looked like it was merged
<https://github.com/apache/lucene-solr/pull/1064>, so I closed it with a
comment. But the second one I checked
<https://github.com/apache/lucene-solr/pull/906/files> looked like the src
changes were merged but maybe the unit test in the PR failed to be merged
<https://github.com/apache/lucene/commit/49631ace9f1ee110d52a207377e4926baef74929>
?

And the script can be used to bulk-add comments. I'm still +1 on that.

But I really don't want to bulk-close all of the PRs. That just makes
these artifacts harder to find in the future. Some of them are still
relevant. I just poked around a bit and found this still-open PR from Simon
<https://github.com/apache/lucene-solr/pull/1925> which is/was a nice
cleanup, from ~ one year ago now, of how DocumentsWriterPerThread tracks
its (tricky!) lifecycle. There are important changes in these still-open
PRs, so I really don't think we should close them. Maybe Simon or Nhat or
myself comes back and cracks the rust off of this PR.

Mike McCandless

http://blog.mikemccandless.com


On Wed, Dec 8, 2021 at 8:57 AM Robert Muir <rcmuir@gmail.com> wrote:

> I'm also now even -1 against bulk-comment. You guys are trying to be
> too sneaky/passive-aggressive/bypass consensus. I'm stopping this shit
> right now in its tracks
>
> On Wed, Dec 8, 2021 at 8:50 AM Robert Muir <rcmuir@gmail.com> wrote:
> >
> > I'm -1 against auto-closing issues, as I already stated on this thread.
> >
> > On Wed, Dec 8, 2021 at 7:53 AM Jan Høydahl <jan.asf@cominvent.com>
> wrote:
> > >
> > > Calm down :)
> > >
> > > As you can read from the last comment, we can choose whether to
> > > * Close with comment and label
> > > * Comment and label only
> > > * Comment only
> > > * Do nothing
> > >
> > > The lucene-solr repo is not dead, it will still be used for
> back-porting bugfixes to branch_8_11 for probably another 12 months.
> > > Byt several branches are dead/archived, and it really makes no sense
> to keep PRs for those alive either.
> > >
> > > This is a proposal for a one-time action, introducing a stale-bot for
> the project, which I can see is more controversial and annoying for sure.
> > >
> > > Jan
> > >
> > > > 8. des. 2021 kl. 13:04 skrev Robert Muir <rcmuir@gmail.com>:
> > > >
> > > > i mean you dont even have anything close to fucking consensus about
> > > > "bulk close" on this thread. most are against it. why be so fucking
> > > > sneaky about it? I don't get it!
> > > >
> > > > On Wed, Dec 8, 2021 at 7:03 AM Robert Muir <rcmuir@gmail.com> wrote:
> > > >>
> > > >> On Wed, Dec 8, 2021 at 7:01 AM Robert Muir <rcmuir@gmail.com>
> wrote:
> > > >>>
> > > >>> I added my vote against bulk close functionality.
> > > >>> it is pretty clear from this thread that several of us are opposed
> to
> > > >>> bulk close.
> > > >>>
> > > >>> somehow the discussion jumped from bulk commenting to bulk close.
> fuck that!
> > > >>>
> > > >>> On Wed, Dec 8, 2021 at 5:39 AM Jan Høydahl <jan.asf@cominvent.com>
> wrote:
> > > >>>>
> > > >>>> I gave it a shot, and it works, so with this change to
> githubPRs.py script: https://github.com/apache/lucene-solr/pull/2625 we
> can close all open PRs with a comment and label with a single command. The
> script can also easily be adapted to other use cases.
> > > >>>>
> > > >>>> Jan
> > > >>>>
> > > >>>>> 8. des. 2021 kl. 01:33 skrev Jan Høydahl <jan.asf@cominvent.com
> >:
> > > >>>>>
> > > >>>>> +1 to bulk commenting on the 274 open PRs with a standard
> message about the need for new PRs.
> > > >>>>> We already have a "stale-closed" label in GitHub, so if we add
> that label to all the issues they can safely be closed without information
> loss.
> > > >>>>> My script
> https://github.com/apache/lucene/blob/main/dev-tools/scripts/githubPRs.py
> can probably be tweaked to do these actions. It uses a python GitHub
> library and already fetches all open PRs, and allows to pass a token, so I
> guess that the token will also allow edits on behalf of the user.
> > > >>>>>
> > > >>>>> Jan
> > > >>>>>
> > > >>>>>> 2. des. 2021 kl. 17:55 skrev Michael Sokolov <
> msokolov@gmail.com>:
> > > >>>>>>
> > > >>>>>> In this specific instance, I don't see the harm in leaving these
> > > >>>>>> issues there since the entire repo is essentially an archival
> artifact
> > > >>>>>> at this point. If we actually want to notify people that "hey
> your
> > > >>>>>> issue is in a dead zone, do you want to revive it? Here's how
> ..." we
> > > >>>>>> could maybe generate some emails? Although I really have no
> idea how
> > > >>>>>> we would accomplish that.
> > > >>>>>>
> > > >>>>>> In general, I'm in favor of cleaning up / closing issues that
> are
> > > >>>>>> clearly not going to be worked.
> > > >>>>>>
> > > >>>>>> For example in JIRA we have so many old issues that they can
> clutter
> > > >>>>>> up search results, making it much harder for new contributors
> > > >>>>>> (especially) to find "interesting" issues that might be
> relevant today
> > > >>>>>> and workable. I have heard various arguments for keeping these
> old
> > > >>>>>> issues: they represent an historical view of the project; "you
> never
> > > >>>>>> know" maybe they become relevant again; and this idea of not
> annoying
> > > >>>>>> people by arbitrarily closing their issue. These all have some
> > > >>>>>> validity, but I we have to strike a balance. I wonder if we can
> > > >>>>>> address them in another way. In JIRA can we keep these old
> issues
> > > >>>>>> while hiding them from default searches. Can we "archive" old
> issues
> > > >>>>>> in some way? Maybe there is a "Status" like Archived that is
> different
> > > >>>>>> from Closed. Anything but Open!
> > > >>>>>>
> > > >>>>>>
> > > >>>>>> On Mon, Nov 29, 2021 at 4:15 PM Mike Drob <mdrob@mdrob.com>
> wrote:
> > > >>>>>>>
> > > >>>>>>> I understand the frustrations around closing somebody’s PR as
> stale, but I also think that there is value in informing the contributors I
> this is never getting solved/fixed/looked at, if this is still important
> please go over there instead.
> > > >>>>>>>
> > > >>>>>>> On Mon, Nov 29, 2021 at 1:55 PM Robert Muir <rcmuir@gmail.com>
> wrote:
> > > >>>>>>>>
> > > >>>>>>>> On Mon, Nov 29, 2021 at 2:49 PM Michael McCandless
> > > >>>>>>>> <lucene@mikemccandless.com> wrote:
> > > >>>>>>>>>
> > > >>>>>>>>> Could we maybe instead bulk-add a comment explaining the
> split and how to take the PR forwards if someone (in the future) has
> itch/time?
> > > >>>>>>>>>
> > > >>>>>>>>> I know we humans love to clean things up, but I think
> leaving such "unclean" things open serves an important purpose. They all
> had importance to at least one person at one point in time, and likely many
> of them are still relevant if they piqued someones curiosity to dig back
> into them. Closing them makes them harder to find for the future developer.
> > > >>>>>>>>>
> > > >>>>>>>>> I'm sure some of them are already resolved/duplicates too.
> If only we could divine which are which.
> > > >>>>>>>>>
> > > >>>>>>>>>
> > > >>>>>>>>
> > > >>>>>>>> +1, I'd rather not auto-close PRs. I'm always frustrated by
> this when
> > > >>>>>>>> I see it in other trackers. Is there a rush to close these
> for some
> > > >>>>>>>> reason?
> > > >>>>>>>>
> > > >>>>>>>>
> ---------------------------------------------------------------------
> > > >>>>>>>> To unsubscribe, e-mail: dev-unsubscribe@lucene.apache.org
> > > >>>>>>>> For additional commands, e-mail: dev-help@lucene.apache.org
> > > >>>>>>>>
> > > >>>>>>
> > > >>>>>>
> ---------------------------------------------------------------------
> > > >>>>>> To unsubscribe, e-mail: dev-unsubscribe@lucene.apache.org
> > > >>>>>> For additional commands, e-mail: dev-help@lucene.apache.org
> > > >>>>>>
> > > >>>>>
> > > >>>>
> > > >>>>
> > > >>>>
> ---------------------------------------------------------------------
> > > >>>> To unsubscribe, e-mail: dev-unsubscribe@lucene.apache.org
> > > >>>> For additional commands, e-mail: dev-help@lucene.apache.org
> > > >>>>
> > > >
> > > > ---------------------------------------------------------------------
> > > > To unsubscribe, e-mail: dev-unsubscribe@lucene.apache.org
> > > > For additional commands, e-mail: dev-help@lucene.apache.org
> > > >
> > >
> > >
> > > ---------------------------------------------------------------------
> > > To unsubscribe, e-mail: dev-unsubscribe@lucene.apache.org
> > > For additional commands, e-mail: dev-help@lucene.apache.org
> > >
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@lucene.apache.org
> For additional commands, e-mail: dev-help@lucene.apache.org
>
>
Re: Closing GitHub PRs [ In reply to ]
I prefer to not auto-close anything. An issue that's open forever doesn't
seem to be harmful. That said, I don't feel strongly enough to veto
whatever the consensus is. I love the bulk-comment proposal!

~ David Smiley
Apache Lucene/Solr Search Developer
http://www.linkedin.com/in/davidwsmiley


On Wed, Dec 8, 2021 at 11:40 AM Michael McCandless <
lucene@mikemccandless.com> wrote:

> I think the script is already proving helpful, finding PRs whose
> corresponding issues were closed. I guess it is possible that some of
> those PRs might still be relevant, but likely most of them should be
> closed? This seems helpful. I spot checked a couple of these. One of
> them indeed looked like it was merged
> <https://github.com/apache/lucene-solr/pull/1064>, so I closed it with a
> comment. But the second one I checked
> <https://github.com/apache/lucene-solr/pull/906/files> looked like the src
> changes were merged but maybe the unit test in the PR failed to be merged
> <https://github.com/apache/lucene/commit/49631ace9f1ee110d52a207377e4926baef74929>
> ?
>
> And the script can be used to bulk-add comments. I'm still +1 on that.
>
> But I really don't want to bulk-close all of the PRs. That just makes
> these artifacts harder to find in the future. Some of them are still
> relevant. I just poked around a bit and found this still-open PR from
> Simon <https://github.com/apache/lucene-solr/pull/1925> which is/was a
> nice cleanup, from ~ one year ago now, of how DocumentsWriterPerThread
> tracks its (tricky!) lifecycle. There are important changes in these
> still-open PRs, so I really don't think we should close them. Maybe Simon
> or Nhat or myself comes back and cracks the rust off of this PR.
>
> Mike McCandless
>
> http://blog.mikemccandless.com
>
>
> On Wed, Dec 8, 2021 at 8:57 AM Robert Muir <rcmuir@gmail.com> wrote:
>
>> I'm also now even -1 against bulk-comment. You guys are trying to be
>> too sneaky/passive-aggressive/bypass consensus. I'm stopping this shit
>> right now in its tracks
>>
>> On Wed, Dec 8, 2021 at 8:50 AM Robert Muir <rcmuir@gmail.com> wrote:
>> >
>> > I'm -1 against auto-closing issues, as I already stated on this thread.
>> >
>> > On Wed, Dec 8, 2021 at 7:53 AM Jan Høydahl <jan.asf@cominvent.com>
>> wrote:
>> > >
>> > > Calm down :)
>> > >
>> > > As you can read from the last comment, we can choose whether to
>> > > * Close with comment and label
>> > > * Comment and label only
>> > > * Comment only
>> > > * Do nothing
>> > >
>> > > The lucene-solr repo is not dead, it will still be used for
>> back-porting bugfixes to branch_8_11 for probably another 12 months.
>> > > Byt several branches are dead/archived, and it really makes no sense
>> to keep PRs for those alive either.
>> > >
>> > > This is a proposal for a one-time action, introducing a stale-bot for
>> the project, which I can see is more controversial and annoying for sure.
>> > >
>> > > Jan
>> > >
>> > > > 8. des. 2021 kl. 13:04 skrev Robert Muir <rcmuir@gmail.com>:
>> > > >
>> > > > i mean you dont even have anything close to fucking consensus about
>> > > > "bulk close" on this thread. most are against it. why be so fucking
>> > > > sneaky about it? I don't get it!
>> > > >
>> > > > On Wed, Dec 8, 2021 at 7:03 AM Robert Muir <rcmuir@gmail.com>
>> wrote:
>> > > >>
>> > > >> On Wed, Dec 8, 2021 at 7:01 AM Robert Muir <rcmuir@gmail.com>
>> wrote:
>> > > >>>
>> > > >>> I added my vote against bulk close functionality.
>> > > >>> it is pretty clear from this thread that several of us are
>> opposed to
>> > > >>> bulk close.
>> > > >>>
>> > > >>> somehow the discussion jumped from bulk commenting to bulk close.
>> fuck that!
>> > > >>>
>> > > >>> On Wed, Dec 8, 2021 at 5:39 AM Jan Høydahl <jan.asf@cominvent.com>
>> wrote:
>> > > >>>>
>> > > >>>> I gave it a shot, and it works, so with this change to
>> githubPRs.py script: https://github.com/apache/lucene-solr/pull/2625 we
>> can close all open PRs with a comment and label with a single command. The
>> script can also easily be adapted to other use cases.
>> > > >>>>
>> > > >>>> Jan
>> > > >>>>
>> > > >>>>> 8. des. 2021 kl. 01:33 skrev Jan Høydahl <jan.asf@cominvent.com
>> >:
>> > > >>>>>
>> > > >>>>> +1 to bulk commenting on the 274 open PRs with a standard
>> message about the need for new PRs.
>> > > >>>>> We already have a "stale-closed" label in GitHub, so if we add
>> that label to all the issues they can safely be closed without information
>> loss.
>> > > >>>>> My script
>> https://github.com/apache/lucene/blob/main/dev-tools/scripts/githubPRs.py
>> can probably be tweaked to do these actions. It uses a python GitHub
>> library and already fetches all open PRs, and allows to pass a token, so I
>> guess that the token will also allow edits on behalf of the user.
>> > > >>>>>
>> > > >>>>> Jan
>> > > >>>>>
>> > > >>>>>> 2. des. 2021 kl. 17:55 skrev Michael Sokolov <
>> msokolov@gmail.com>:
>> > > >>>>>>
>> > > >>>>>> In this specific instance, I don't see the harm in leaving
>> these
>> > > >>>>>> issues there since the entire repo is essentially an archival
>> artifact
>> > > >>>>>> at this point. If we actually want to notify people that "hey
>> your
>> > > >>>>>> issue is in a dead zone, do you want to revive it? Here's how
>> ..." we
>> > > >>>>>> could maybe generate some emails? Although I really have no
>> idea how
>> > > >>>>>> we would accomplish that.
>> > > >>>>>>
>> > > >>>>>> In general, I'm in favor of cleaning up / closing issues that
>> are
>> > > >>>>>> clearly not going to be worked.
>> > > >>>>>>
>> > > >>>>>> For example in JIRA we have so many old issues that they can
>> clutter
>> > > >>>>>> up search results, making it much harder for new contributors
>> > > >>>>>> (especially) to find "interesting" issues that might be
>> relevant today
>> > > >>>>>> and workable. I have heard various arguments for keeping
>> these old
>> > > >>>>>> issues: they represent an historical view of the project; "you
>> never
>> > > >>>>>> know" maybe they become relevant again; and this idea of not
>> annoying
>> > > >>>>>> people by arbitrarily closing their issue. These all have some
>> > > >>>>>> validity, but I we have to strike a balance. I wonder if we can
>> > > >>>>>> address them in another way. In JIRA can we keep these old
>> issues
>> > > >>>>>> while hiding them from default searches. Can we "archive" old
>> issues
>> > > >>>>>> in some way? Maybe there is a "Status" like Archived that is
>> different
>> > > >>>>>> from Closed. Anything but Open!
>> > > >>>>>>
>> > > >>>>>>
>> > > >>>>>> On Mon, Nov 29, 2021 at 4:15 PM Mike Drob <mdrob@mdrob.com>
>> wrote:
>> > > >>>>>>>
>> > > >>>>>>> I understand the frustrations around closing somebody’s PR as
>> stale, but I also think that there is value in informing the contributors I
>> this is never getting solved/fixed/looked at, if this is still important
>> please go over there instead.
>> > > >>>>>>>
>> > > >>>>>>> On Mon, Nov 29, 2021 at 1:55 PM Robert Muir <rcmuir@gmail.com>
>> wrote:
>> > > >>>>>>>>
>> > > >>>>>>>> On Mon, Nov 29, 2021 at 2:49 PM Michael McCandless
>> > > >>>>>>>> <lucene@mikemccandless.com> wrote:
>> > > >>>>>>>>>
>> > > >>>>>>>>> Could we maybe instead bulk-add a comment explaining the
>> split and how to take the PR forwards if someone (in the future) has
>> itch/time?
>> > > >>>>>>>>>
>> > > >>>>>>>>> I know we humans love to clean things up, but I think
>> leaving such "unclean" things open serves an important purpose. They all
>> had importance to at least one person at one point in time, and likely many
>> of them are still relevant if they piqued someones curiosity to dig back
>> into them. Closing them makes them harder to find for the future developer.
>> > > >>>>>>>>>
>> > > >>>>>>>>> I'm sure some of them are already resolved/duplicates too.
>> If only we could divine which are which.
>> > > >>>>>>>>>
>> > > >>>>>>>>>
>> > > >>>>>>>>
>> > > >>>>>>>> +1, I'd rather not auto-close PRs. I'm always frustrated by
>> this when
>> > > >>>>>>>> I see it in other trackers. Is there a rush to close these
>> for some
>> > > >>>>>>>> reason?
>> > > >>>>>>>>
>> > > >>>>>>>>
>> ---------------------------------------------------------------------
>> > > >>>>>>>> To unsubscribe, e-mail: dev-unsubscribe@lucene.apache.org
>> > > >>>>>>>> For additional commands, e-mail: dev-help@lucene.apache.org
>> > > >>>>>>>>
>> > > >>>>>>
>> > > >>>>>>
>> ---------------------------------------------------------------------
>> > > >>>>>> To unsubscribe, e-mail: dev-unsubscribe@lucene.apache.org
>> > > >>>>>> For additional commands, e-mail: dev-help@lucene.apache.org
>> > > >>>>>>
>> > > >>>>>
>> > > >>>>
>> > > >>>>
>> > > >>>>
>> ---------------------------------------------------------------------
>> > > >>>> To unsubscribe, e-mail: dev-unsubscribe@lucene.apache.org
>> > > >>>> For additional commands, e-mail: dev-help@lucene.apache.org
>> > > >>>>
>> > > >
>> > > >
>> ---------------------------------------------------------------------
>> > > > To unsubscribe, e-mail: dev-unsubscribe@lucene.apache.org
>> > > > For additional commands, e-mail: dev-help@lucene.apache.org
>> > > >
>> > >
>> > >
>> > > ---------------------------------------------------------------------
>> > > To unsubscribe, e-mail: dev-unsubscribe@lucene.apache.org
>> > > For additional commands, e-mail: dev-help@lucene.apache.org
>> > >
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: dev-unsubscribe@lucene.apache.org
>> For additional commands, e-mail: dev-help@lucene.apache.org
>>
>>