Re: Welcome Houston Putman to the PMC
Thanks everyone! I'm very excited to continue growing and improving the community with y'all! - Houston On Thu, Dec 3, 2020 at 6:39 AM Michael Sokolov wrote: > Welcome, Houston! > > On Wed, Dec 2, 2020, 2:34 PM David Smiley wrote: > >> Welcome Houston! >> >> ~ David Smiley >> Apache Lucene/Solr Search Developer >> http://www.linkedin.com/in/davidwsmiley >> >> >> On Tue, Dec 1, 2020 at 4:20 PM Mike Drob wrote: >> >>> I am pleased to announce that Houston Putman has accepted the PMC's >>> invitation to join. >>> >>> Congratulations and welcome, Houston! >>> >>> - >>> To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org >>> For additional commands, e-mail: dev-h...@lucene.apache.org >>> >>>
Re: SOLR: Why do we have a CHANGES.txt/md to maintain?
Couldn't help pitching in here and making a humble request. The CHANGES.txt has been of immense help for us for determining the right upgrade version for our production deployments. So CHANGES.txt or no CHANGES.txt, I hope we'll retain a mechanism to clearly be able to track the changes in subsequent versions. Thanks, Rahul On Mon, Nov 30, 2020 at 9:04 AM David Smiley wrote: > I get your point on different audiences... sometimes I peer-review us on > dubiously written CHANGES.txt entries to be more user friendly. However, > this attention could and should be given to JIRA issue summaries as well. > We all benefit from that. Also, for Solr in particular, the need for > examining CHANGES / JIRA is reduced because we have a solr-upgrade-notes.adoc > which is editorialized and covers just the important stuff; no minor > matters. We link to this from release announcements. > > ~ David Smiley > Apache Lucene/Solr Search Developer > http://www.linkedin.com/in/davidwsmiley > > > On Mon, Nov 30, 2020 at 3:29 AM Adrien Grand wrote: > >> I have a preference for maintaining a separate CHANGES file because it >> allows us to keep JIRA focused for a committer/contributor audience while >> the CHANGES file can describe changes that matter for users. Elasticsearch >> uses a similar mechanism for release notes to what you are proposing, using >> GitHub instead of JIRA. It works well, but in my opinion the Lucene/Solr >> process produces better curated release notes. >> >> On Mon, Nov 30, 2020 at 12:25 AM David Smiley wrote: >> >>> Well the commit history remains there as well and was converted from SVN >>> and may eventually be converted to something else. My point is that it has >>> been retained. On release boundaries, we could not only distribute >>> Changes.html (a JIRA export) in the assembly (tar.gz) but we could also >>> commit it to source control on each release branch, and thus will transfer >>> along with source control into the future, which is way more convenient >>> than digging up an old binary. >>> >>> ~ David Smiley >>> Apache Lucene/Solr Search Developer >>> http://www.linkedin.com/in/davidwsmiley >>> >>> >>> On Sun, Nov 29, 2020 at 5:55 AM Dawid Weiss >>> wrote: >>> Changes in the repository stay there forever (think cvs/svn/git/whatever comes next...). External tools change all the time. This is the benefit I see. Dawid On Sun, Nov 29, 2020 at 6:32 AM David Smiley wrote: > > After recently proposing per-module CHANGES.md... I think I'd actually rather not have any CHANGES file at all to maintain. I'd rather go to JIRA with a bit better hygiene for metadata like components==contrib/module, and have some convenient links sprinkled about so that it's a convenient click away from each module. This proposal may not be as compelling for Lucene which has no solr-upgrade-notes.adoc file. > > Maintaining this CHANGES file (or files) is a pain. Formatting it just-so & conversion to HTML & other scripts manipulating it in dev-tools (e.g. add version), and branch syncing. It's commonly a source of merge conflicts more than any other file. It's an annoying step with GitHub PRs in particular. Why do we bother? Instead, on releases, provide a JIRA link to display all fixed issues grouped by issue type. We could export it to a file for direct inclusion in the distribution. JIRA even has a feature for this -- here's a direct link for 8.7: https://issues.apache.org/jira/secure/ReleaseNote.jspa?projectId=12310230=12348463 Notice the HTML version at the bottom. It could be dumped into the release binaries. > Issue summaries tend to be much shorter than CHANGES.txt bullets but I think that's okay because it's not the only information available for those who want to know more. Remember there is also all the other metadata in JIRA a user can examine, there are commit messages, sometimes PRs, and there's solr-upgrade-notes.adoc which ought to be the starting point for someone interested in a release. > > It's been argued that contributors should get attribution here but we could maintain a separate contributors file to acknowledge people by name for inclusion with the Solr distribution -- one that has a link to JIRA and GitHub even. > > ~ David Smiley > Apache Lucene/Solr Search Developer > http://www.linkedin.com/in/davidwsmiley - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org >> >> -- >> Adrien >> >
Re: Solr: Separate CHANGES.txt for Docker, SolrJ, Contribs, ...
For some days now, the prometheus exporter & Docker modules have their own CHANGES.md on master. I was about to add a CHANGES.md for the rest of the contribs last week... but... instead ***I'm going to reverse this***; merge the entries into solr/CHANGES.txt. I still think it's better than a single CHANGES.txt for Solr, and I'd even more prefer no CHANGES.txt to maintain at all. But I don't have time/energy to pursue either approach. This limbo state at present isn't cool, so I'm choosing to back out. What follows is what I wrote last week prior to jumping on the idea that I'd rather we not bother with any CHANGES.txt. I'm including it here as a sort of note to self and others who want to explore this topic more. The questions therein are _not_ an active prompt to the community at this time. - I've noticed some build/release infrastructure that either assumes only Lucene & Solr have a CHANGES.txt, or don't know how to handle Markdown. * gradlew changesToHtml on the Lucene & Solr "documentation" sub-projects, which executes a changes2html.pl (a perl script) which parses CHANGES.txt to produce a Changes.html file. Here's what that looks like: https://lucene.apache.org/solr/8_7_0/changes/Changes.html Question: Might it be good enough if this file had a header with links to each contrib's CHANGES.md as viewed on GitHub, which renders the Markdown to a browser?: https://github.com/apache/lucene-solr/blob/master/solr/contrib/prometheus-exporter/CHANGES.md (the "master" would change to 9.0.0 upon the release). The biggest benefit of changes2html.pl is that it makes SOLR- links to JIRA. In the Markdown files we could link-ify them ourselves as we edit the file -- rather trivial to maintain; in practice we'd copy another link nearby and edit it to have the right JIRA reference at the tail end of the URL and for the display part. * releaseWizard.yaml invokes releasedJirasRegex.py on CHANGES.txt which produces a regular expression matching LUCENE- & SOLR- JIRA references for the most recent release. It doesn't understand the markdown based syntax for the release headings in CHANGES.md although a small change in the heading syntax choice could make that trivial to fix. Any way... the goal here is for the RM to sync the changes on the release branch over to master branch. Today, the RM does this for Lucene & Solr. I suppose additional CHANGES.md per contrib/module implies doing this for each of those as well. :-( At least contrib/modules change at a slow pace but still. On Tue, Nov 24, 2020 at 4:48 PM Alexandre Rafalovitch wrote: > Absolutely. > > What I was trying to say is that when it comes to implementation, > there may be a choice of strategies to do so within the same scope. A > strategy that aligns better with something that - with more work - > eventually becomes true structured data may have more long-term value > than a strategy that does not. > > Hope that makes sense. > > Regards, >Alex. > > On Tue, 24 Nov 2020 at 12:13, David Smiley wrote: > > > > I'd rather not scope-creep my proposal here further. Granted I ventured > into TXT -> Markdown. > > > > ~ David Smiley > > Apache Lucene/Solr Search Developer > > http://www.linkedin.com/in/davidwsmiley > > > > > > On Tue, Nov 24, 2020 at 9:37 AM Alexandre Rafalovitch < > arafa...@gmail.com> wrote: > >> > >> And - afterthought - if there is an easily parsable format, the parser > >> could even run at the commit time on GitHub to make sure that issue > >> numbers are correct, names are included and formatting is not broken. > >> > >> Regards, > >>Alex. > >> > >> On Mon, 23 Nov 2020 at 19:38, Alexandre Rafalovitch > wrote: > >> > > >> > Should we switch to a structured format, instead of current format > that tools struggle to convert. > >> > > >> > Something that one could push into Solr would have been nice... > >> > > >> > Regards, > >> > Alex > >> > > >> > On Mon., Nov. 23, 2020, 4:47 p.m. David Smiley, > wrote: > >> >> > >> >> I pushed a commit to a PR for the prometheus exporter that includes > a CHANGES.md > >> >> > https://github.com/apache/lucene-solr/pull/1972/commits/bec84ce2a1d60480ce0c54b78e83a70f83e7b058 > >> >> and likewise for a commit to a PR for the docker module: > >> >> > https://github.com/apache/lucene-solr/pull/2083/commits/540f8117153d12bd13441326035820f97084878a > >> >> > >> >> * I chose the Markdown format. This is an opportune time to > switch. This meant changing " 9.0 " to "9.0" then "==" beneath > it, but otherwise, no changes! > >> >> * I chose to start this for 9.0. Any changes prior to 9.0 I think > should continue to do things as we have been doing things historically. > >> >> * I considered updating dev-tools/scripts/addVersion.py but > ultimately elected not to. I think the rate of changes in each module will > be low enough that it's not a big deal to maintain it manually. Plus, I > confess I'm less motivated to touch Python ;-) but I'd be more
Re: Welcome Houston Putman to the PMC
Welcome, Houston! On Wed, Dec 2, 2020, 2:34 PM David Smiley wrote: > Welcome Houston! > > ~ David Smiley > Apache Lucene/Solr Search Developer > http://www.linkedin.com/in/davidwsmiley > > > On Tue, Dec 1, 2020 at 4:20 PM Mike Drob wrote: > >> I am pleased to announce that Houston Putman has accepted the PMC's >> invitation to join. >> >> Congratulations and welcome, Houston! >> >> - >> To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org >> For additional commands, e-mail: dev-h...@lucene.apache.org >> >>
Re: Welcome Houston Putman to the PMC
Congratulations and welcome to the PMC, Houston. On Tue, Dec 1, 2020 at 10:19 PM Mike Drob wrote: > I am pleased to announce that Houston Putman has accepted the PMC's > invitation to join. > > Congratulations and welcome, Houston! > > - > To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org > For additional commands, e-mail: dev-h...@lucene.apache.org > >
Re: Welcome Houston Putman to the PMC
Welcome Houston! ~ David Smiley Apache Lucene/Solr Search Developer http://www.linkedin.com/in/davidwsmiley On Tue, Dec 1, 2020 at 4:20 PM Mike Drob wrote: > I am pleased to announce that Houston Putman has accepted the PMC's > invitation to join. > > Congratulations and welcome, Houston! > > - > To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org > For additional commands, e-mail: dev-h...@lucene.apache.org > >
Re: [JENKINS] Lucene » Lucene-Solr-Check-master - Build # 972 - Unstable!
https://issues.apache.org/jira/browse/SOLR-15026 : Date: Wed, 2 Dec 2020 18:47:51 + (UTC) : From: Apache Jenkins Server : Reply-To: dev@lucene.apache.org : To: bui...@lucene.apache.org : Subject: [JENKINS] Lucene » Lucene-Solr-Check-master - Build # 972 - Unstable! : : Build: https://ci-builds.apache.org/job/Lucene/job/Lucene-Solr-Check-master/972/ : : 1 tests failed. : FAILED: org.apache.solr.cloud.MiniSolrCloudClusterTest.testSolrHomeAndResourceLoaders : : Error Message: : org.apache.solr.client.solrj.SolrServerException: IOException occurred when talking to server at: https://127.0.0.1:34219/solr : : Stack Trace: : org.apache.solr.client.solrj.SolrServerException: IOException occurred when talking to server at: https://127.0.0.1:34219/solr : at __randomizedtesting.SeedInfo.seed([806A85748BD81F48:37548FA7602CB5FD]:0) : at org.apache.solr.client.solrj.impl.HttpSolrClient.executeMethod(HttpSolrClient.java:712) : at org.apache.solr.client.solrj.impl.HttpSolrClient.request(HttpSolrClient.java:269) : at org.apache.solr.client.solrj.impl.HttpSolrClient.request(HttpSolrClient.java:251) : at org.apache.solr.client.solrj.impl.LBSolrClient.doRequest(LBSolrClient.java:390) : at org.apache.solr.client.solrj.impl.LBSolrClient.request(LBSolrClient.java:360) : at org.apache.solr.client.solrj.impl.BaseCloudSolrClient.sendRequest(BaseCloudSolrClient.java:1168) : at org.apache.solr.client.solrj.impl.BaseCloudSolrClient.requestWithRetryOnStaleState(BaseCloudSolrClient.java:931) : at org.apache.solr.client.solrj.impl.BaseCloudSolrClient.request(BaseCloudSolrClient.java:865) : at org.apache.solr.client.solrj.SolrRequest.process(SolrRequest.java:229) : at org.apache.solr.client.solrj.SolrRequest.process(SolrRequest.java:246) : at org.apache.solr.cloud.MiniSolrCloudClusterTest.testSolrHomeAndResourceLoaders(MiniSolrCloudClusterTest.java:125) : at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Native Method) : at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62) : at java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) : at java.base/java.lang.reflect.Method.invoke(Method.java:566) : at com.carrotsearch.randomizedtesting.RandomizedRunner.invoke(RandomizedRunner.java:1754) : at com.carrotsearch.randomizedtesting.RandomizedRunner$8.evaluate(RandomizedRunner.java:942) : at com.carrotsearch.randomizedtesting.RandomizedRunner$9.evaluate(RandomizedRunner.java:978) : at com.carrotsearch.randomizedtesting.RandomizedRunner$10.evaluate(RandomizedRunner.java:992) : at com.carrotsearch.randomizedtesting.rules.SystemPropertiesRestoreRule$1.evaluate(SystemPropertiesRestoreRule.java:57) : at org.junit.rules.RunRules.evaluate(RunRules.java:20) : at org.apache.lucene.util.TestRuleSetupTeardownChained$1.evaluate(TestRuleSetupTeardownChained.java:49) : at org.apache.lucene.util.AbstractBeforeAfterRule$1.evaluate(AbstractBeforeAfterRule.java:45) : at org.apache.lucene.util.TestRuleThreadAndTestName$1.evaluate(TestRuleThreadAndTestName.java:48) : at org.apache.lucene.util.TestRuleIgnoreAfterMaxFailures$1.evaluate(TestRuleIgnoreAfterMaxFailures.java:64) : at org.apache.lucene.util.TestRuleMarkFailure$1.evaluate(TestRuleMarkFailure.java:47) : at org.junit.rules.RunRules.evaluate(RunRules.java:20) : at com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36) : at com.carrotsearch.randomizedtesting.ThreadLeakControl$StatementRunner.run(ThreadLeakControl.java:370) : at com.carrotsearch.randomizedtesting.ThreadLeakControl.forkTimeoutingTask(ThreadLeakControl.java:819) : at com.carrotsearch.randomizedtesting.ThreadLeakControl$3.evaluate(ThreadLeakControl.java:470) : at com.carrotsearch.randomizedtesting.RandomizedRunner.runSingleTest(RandomizedRunner.java:951) : at com.carrotsearch.randomizedtesting.RandomizedRunner$5.evaluate(RandomizedRunner.java:836) : at com.carrotsearch.randomizedtesting.RandomizedRunner$6.evaluate(RandomizedRunner.java:887) : at com.carrotsearch.randomizedtesting.RandomizedRunner$7.evaluate(RandomizedRunner.java:898) : at com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36) : at com.carrotsearch.randomizedtesting.rules.SystemPropertiesRestoreRule$1.evaluate(SystemPropertiesRestoreRule.java:57) : at org.junit.rules.RunRules.evaluate(RunRules.java:20) : at org.apache.lucene.util.AbstractBeforeAfterRule$1.evaluate(AbstractBeforeAfterRule.java:45) : at com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36) : at org.apache.lucene.util.TestRuleStoreClassName$1.evaluate(TestRuleStoreClassName.java:41) : at
Re: Welcome Houston Putman to the PMC
Welcome Houston! Joel Bernstein http://joelsolr.blogspot.com/ On Wed, Dec 2, 2020 at 11:25 AM Namgyu Kim wrote: > Congratulations and welcome, Houston! :D > > On Thu, Dec 3, 2020 at 12:24 AM Steve Rowe wrote: > >> Welcome Houston! >> >> -- >> Steve >> >> > On Dec 1, 2020, at 4:19 PM, Mike Drob wrote: >> > >> > I am pleased to announce that Houston Putman has accepted the PMC's >> invitation to join. >> > >> > Congratulations and welcome, Houston! >> > >> > - >> > To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org >> > For additional commands, e-mail: dev-h...@lucene.apache.org >> > >> >> >> - >> To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org >> For additional commands, e-mail: dev-h...@lucene.apache.org >> >>
Re: Welcome Houston Putman to the PMC
Congratulations and welcome, Houston! :D On Thu, Dec 3, 2020 at 12:24 AM Steve Rowe wrote: > Welcome Houston! > > -- > Steve > > > On Dec 1, 2020, at 4:19 PM, Mike Drob wrote: > > > > I am pleased to announce that Houston Putman has accepted the PMC's > invitation to join. > > > > Congratulations and welcome, Houston! > > > > - > > To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org > > For additional commands, e-mail: dev-h...@lucene.apache.org > > > > > - > To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org > For additional commands, e-mail: dev-h...@lucene.apache.org > >
Re: Welcome Houston Putman to the PMC
Welcome Houston! -- Steve > On Dec 1, 2020, at 4:19 PM, Mike Drob wrote: > > I am pleased to announce that Houston Putman has accepted the PMC's > invitation to join. > > Congratulations and welcome, Houston! > > - > To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org > For additional commands, e-mail: dev-h...@lucene.apache.org > - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
Re: Welcome Houston Putman to the PMC
Welcome Houston! On Wed, Dec 2, 2020 at 1:40 PM Erick Erickson wrote: > Welcome Houston! > > > On Dec 2, 2020, at 1:34 AM, Shalin Shekhar Mangar < > shalinman...@gmail.com> wrote: > > > > Congratulations Houston! > > > > On Wed, Dec 2, 2020 at 2:50 AM Mike Drob wrote: > > I am pleased to announce that Houston Putman has accepted the PMC's > invitation to join. > > > > Congratulations and welcome, Houston! > > > > - > > To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org > > For additional commands, e-mail: dev-h...@lucene.apache.org > > > > > > > > -- > > Regards, > > Shalin Shekhar Mangar. > > > - > To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org > For additional commands, e-mail: dev-h...@lucene.apache.org > > -- Adrien
Re: Welcome Houston Putman to the PMC
Welcome Houston! > On Dec 2, 2020, at 1:34 AM, Shalin Shekhar Mangar > wrote: > > Congratulations Houston! > > On Wed, Dec 2, 2020 at 2:50 AM Mike Drob wrote: > I am pleased to announce that Houston Putman has accepted the PMC's > invitation to join. > > Congratulations and welcome, Houston! > > - > To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org > For additional commands, e-mail: dev-h...@lucene.apache.org > > > > -- > Regards, > Shalin Shekhar Mangar. - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
