It's more than just SOLR-10760, actually. SOLR-10760 is just about updating the example schemas. No problem, easy to do, we could commit it today. But I think focusing on that issue obscures the larger situation.
If we care about having a quality application, though, we need to address the other points Hoss shared with Anshum yesterday. This relies on the test randomization in SOLR-10807 to be sure. The strategy there is to create sub-tasks for each test schema file you will randomize and fix/file jiras/suppress tests depending on what breaks. That effort can be done in parallel, and doesn't rely on Hoss or Steve because of some magic knowledge only they possess. However, it will go faster if more people help. When that's done, assuming we're confident we found everything that may be broken, can we live with the broken features in a 7.0 release? I think we should understand there will be another decision point once we're confident we have updated all the tests and found as many bugs as we can. So, my overall point is that if A) we agree that we want to deprecate Trie* numeric fields, and B) we want to hold up the 7.0 release until that's done, it's more than just updating the example schemas if we want to ensure a quality app for users. We still need to fix the tests and also fix bugs that are going to be really painful for users. And to get all that done soon, we definitely need some more volunteers. On Tue, Jul 11, 2017 at 10:28 AM, Anshum Gupta <ansh...@apple.com> wrote: > Here’s an update for 7.0 release. > > We are (rightfully) waiting for SOLR-10760 to be completed so that we could > deprecate all Trie/LegacyNumeric based fields in 7.0. I discussed this with > Hoss, and Steve Rowe, and here are the 2 things that Hoss highlighted that > were not directly related for 7.0, but for being able to comfortable > deprecate those fields: > > "a) points fields have been around for many 6.x releases, but a lot of > features silently fail (or fail in weird ways) if you use points ... so i > wnat to get those bugs found and documented > b) i want the test randomization in place so that as people create new > functionality w/ explicit/implicit assumptions about *either* points or > tries the tests will fail on them (someitmes)” > > While we wait for this, we should now only get bug fixes and critical > deprecations into branch_7_0. > > P.S: Like always, if someone thinks otherwise, let everyone else know. > > -Anshum > > > > On Jul 10, 2017, at 8:50 AM, Cassandra Targett <casstarg...@gmail.com> > wrote: > > Thanks Steve. > > On Mon, Jul 10, 2017 at 10:35 AM, Anshum Gupta <ans...@anshumgupta.net> > wrote: > > Thanks Steve, and Cassandra. > > On Mon, Jul 10, 2017 at 8:29 AM Steve Rowe <sar...@gmail.com> wrote: > > > > On Jul 10, 2017, at 11:04 AM, Cassandra Targett <casstarg...@gmail.com> > wrote: > > We also need Solr Ref Guide Jenkins jobs for 7.x and 7.0 - Steve Rowe > maybe you could help with that? > > > I created 7.x & 7.0 ref guide jobs by cloning the master job. > > On Tue, Jul 4, 2017 at 6:53 AM, Uwe Schindler <u...@thetaphi.de> wrote: > > > I enabled the 7.x builds on ASF and Policeman Jenkins. I did not yet > create > 7.0 jobs. I just want the 7.x builds succeed. > > > I went ahead and created the 7.0 jobs on ASF Jenkins - seems like the 7.x > jobs are behaving normally. I did not create the 7.0 jobs on Policeman > Jenkins. > > I disabled all 6.x builds. I’d like to nuke them at some and just leave > the > 6.6 builds disabled as a fallback for a new point release. This goes in > line > with Erick’s question about JIRA labels! I’d not go for a 6.7 release, > we > should just focus on 7.0. > > > I also disabled the 6.x ref guide job. > > -- > Steve > www.lucidworks.com > > > --------------------------------------------------------------------- > 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 > > --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
