Re: Propose JIRA "Fix Version" remove from create-issue screen

2020-02-07 Thread David Smiley
Issue filed: https://issues.apache.org/jira/browse/INFRA-19835 ~ David Smiley Apache Lucene/Solr Search Developer http://www.linkedin.com/in/davidwsmiley On Fri, Feb 7, 2020 at 4:27 PM Anshum Gupta wrote: > +1 on Option A. > > Seems like it'll require an INFRA ticket though. > > On Sun, Feb

Re: Propose JIRA "Fix Version" remove from create-issue screen

2020-02-07 Thread Anshum Gupta
+1 on Option A. Seems like it'll require an INFRA ticket though. On Sun, Feb 2, 2020 at 9:03 PM David Smiley wrote: > I think too often a "Fix Version" is set prematurely, especially by > contributors who don't know better and seem to choose arbitrary values, > thus making this JIRA field less

Re: Propose JIRA "Fix Version" remove from create-issue screen

2020-02-07 Thread Cassandra Targett
Yes, you’re correct. We currently have only one screen used for create, edit, and view in each project. To change which fields show in any one of those views, we need another screen. Only Jira administrators can make a screen and update the screen scheme to use it, and, for our Jira, only

Info on document number limitations

2020-02-07 Thread Doug Tarr
Hi! I'm working on a team that is building a lucene based search platform. I've been lurking on this list for a while as we are spooling up on learning the various components of Lucene. Thank you all for your amazing work! I'm interested in learning more about what work has been done around

Re: Propose JIRA "Fix Version" remove from create-issue screen

2020-02-07 Thread David Smiley
Cassandra: I believe you have more JIRA administrative experience than I. I notice Solr has one "screen" used for create, edit, and view. "SOLR-JIRA-PROJECT" is the name of the screen. It appears I need to request that a JIRA administrator create a new screen for us that is associated only with

Re: [JENKINS] Lucene-Solr-NightlyTests-master - Build # 2096 - Still Unstable

2020-02-07 Thread Erick Erickson
Adrien: We were seeing this very rarely after I changed to using async logging. There was a time when some logging tests would have log messages queued up for delivery in a test with lots and lots and lots of output that would somehow bleed over into an ensuing test and trigger this condition.

Re: Commit / Code Review Policy

2020-02-07 Thread David Smiley
I neglected to try and close up this long thread on the subject of code review guidance. In the project's board report to the ASF, I asked for help; Daniel Ruggeri (an ASF VP) graciously volunteered. He's on the "To" line to my message here; he's not a member of our dev list. Daniel: Thanks in