Hey Ignacio, I think in the course of cutting the 8.2 release, you might've broken precommit on master. I'm getting the following error consistently:
[xmlproperty] [Fatal Error] solr.rdf:685:5: The element type "release" must be terminated by the matching end-tag "</release>". ... BUILD FAILED When I look at dev-tools/doap/solr.rdf, the new 8.2.0 release section doesn't have a closing tag. Best, Jason On Fri, Jul 19, 2019 at 2:50 AM Adrien Grand <jpou...@gmail.com> wrote: > > +1 > > On Thu, Jul 18, 2019 at 9:38 AM Ignacio Vera <iver...@gmail.com> wrote: > > > > Hi, > > > > As there is no blockers for the release of Lucene/Solr 8.2 and the branch > > is stable I am planning to build the first Release candidate tomorrow > > (Friday). Please let us know if there is any concern/ issue that needs to > > be dealt with before moving to the next step. > > > > > > On Mon, Jul 15, 2019 at 11:32 PM Michael Sokolov <msoko...@gmail.com> wrote: > >> > >> Thanks, good catch, I'll set the current version back to 6. I haven't > >> seen any comments on the (trivial) PR, so I'll push tonight in order > >> to keep the release train rolling > >> > >> On Mon, Jul 15, 2019 at 3:28 PM David Smiley <david.w.smi...@gmail.com> > >> wrote: > >> > > >> > Disable or rollback; I'm good either way. I think you should un-bump > >> > the FST version since the feature becomes entirely experimental. > >> > > >> > ~ David Smiley > >> > Apache Lucene/Solr Search Developer > >> > http://www.linkedin.com/in/davidwsmiley > >> > > >> > > >> > On Mon, Jul 15, 2019 at 12:34 PM Ishan Chattopadhyaya > >> > <ichattopadhy...@gmail.com> wrote: > >> >> > >> >> +1 to rollback and having a 8.3 as soon as we nail this down (even if > >> >> that is days or 1-2 weeks after 8.2). > >> >> > >> >> On Mon, 15 Jul, 2019, 9:22 PM Michael Sokolov, <msoko...@gmail.com> > >> >> wrote: > >> >>> > >> >>> I guess whether we roll back depends on timing. I think we are close > >> >>> to a release though, and these changes are complex and will require > >> >>> further testing, so rollback seems reasonable to me. I think from code > >> >>> management perspective it will be simplest to disable direct > >> >>> addressing for now, rather than actually reverting the various commits > >> >>> that are in place. I can post a patch doing that today. > >> >>> > >> >>> I like the ideas you have for compressing FSTs further. It was > >> >>> bothering me that we store the labels needlessly. I do think that > >> >>> before making more radical changes to Arc though, I would like to add > >> >>> some encapsulation so that we can be a bit freer without being > >> >>> concerned about the abstraction leaking (Several classes depend on the > >> >>> Arc internals today). EG I'd like to make its members private and add > >> >>> getters. I know this is a performance-sensitive area, and maybe we had > >> >>> a reason for not using them? Do we have some experience that suggests > >> >>> that would be a performance issue? My assumption is that JIT > >> >>> compilation would make that free, but I haven't tested. > >> >>> > >> >>> On Mon, Jul 15, 2019 at 11:36 AM Adrien Grand <jpou...@gmail.com> > >> >>> wrote: > >> >>> > > >> >>> > That would be great. I wonder that we could also make the encoding a > >> >>> > bit more efficient. For instance I noticed that arc metadata is > >> >>> > pretty > >> >>> > large in some cases (in the 10-20 bytes) which make gaps very costly. > >> >>> > Associating each label with a dense id and having an intermediate > >> >>> > lookup, ie. lookup label -> id and then id->arc offset instead of > >> >>> > doing label->arc directly could save a lot of space in some cases? > >> >>> > Also it seems that we are repeating the label in the arc metadata > >> >>> > when > >> >>> > array-with-gaps is used, even though it shouldn't be necessary since > >> >>> > the label is implicit from the address? > >> >>> > > >> >>> > Do you think we can have a mitigation for worst-case scenarii in 8.2 > >> >>> > or should we revert from branch_8_2 to keep the release process going > >> >>> > and work on this for 8.3? > >> >>> > > >> >>> > On Mon, Jul 15, 2019 at 5:12 PM Michael Sokolov <msoko...@gmail.com> > >> >>> > wrote: > >> >>> > > > >> >>> > > Thanks for the nice test, Adrien. Yes, the tradeoff of direct > >> >>> > > addressing is heavily data-dependent. I think we can improve the > >> >>> > > situation here by tracking, per-FST instance, the size increase > >> >>> > > we're > >> >>> > > seeing while building (or perhaps do a preliminary pass before > >> >>> > > building) in order to decide whether to apply the encoding. > >> >>> > > > >> >>> > > On Mon, Jul 15, 2019 at 9:02 AM Adrien Grand <jpou...@gmail.com> > >> >>> > > wrote: > >> >>> > > > > >> >>> > > > I dug this a bit and suspect that the issue is mostly with one > >> >>> > > > field > >> >>> > > > that is not part of the data but auto-generated: the ID field. > >> >>> > > > It is a > >> >>> > > > slight variant of Flake IDs, so it's not random, it includes a > >> >>> > > > timestamp and a sequence number, and I suspect that its patterns > >> >>> > > > combined with the larger alphabet than ascii makes this size > >> >>> > > > increase > >> >>> > > > more likely than with the data set you tested against. > >> >>> > > > > >> >>> > > > For instance I ran the following code with direct array > >> >>> > > > addressing on > >> >>> > > > and off to simulate a worst-case scenario. > >> >>> > > > > >> >>> > > > public static void main(String[] args) throws IOException { > >> >>> > > > Directory dir = FSDirectory.open(Paths.get("/tmp/a")); > >> >>> > > > IndexWriter w = new IndexWriter(dir, new > >> >>> > > > IndexWriterConfig().setOpenMode(OpenMode.CREATE)); > >> >>> > > > byte[] b = new byte[5]; > >> >>> > > > Random r = new Random(0); > >> >>> > > > for (int i = 0; i < 1000000; ++i) { > >> >>> > > > r.nextBytes(b); > >> >>> > > > for (int j = 0; j < b.length; ++j) { > >> >>> > > > b[j] &= 0xfc; // make this byte a multiple of 4 > >> >>> > > > } > >> >>> > > > Document doc = new Document(); > >> >>> > > > StringField field = new StringField("f", new BytesRef(b), > >> >>> > > > Store.NO); > >> >>> > > > doc.add(field); > >> >>> > > > w.addDocument(doc); > >> >>> > > > } > >> >>> > > > w.forceMerge(1); > >> >>> > > > IndexReader reader = DirectoryReader.open(w); > >> >>> > > > w.close(); > >> >>> > > > if (reader.leaves().size() != 1) { > >> >>> > > > throw new Error(); > >> >>> > > > } > >> >>> > > > LeafReader leaf = reader.leaves().get(0).reader(); > >> >>> > > > System.out.println(((SegmentReader) leaf).ramBytesUsed()); > >> >>> > > > reader.close(); > >> >>> > > > dir.close(); > >> >>> > > > } > >> >>> > > > > >> >>> > > > When direct addressing is enabled (default), I get 586079. If I > >> >>> > > > disable direct addressing by applying the below patch, then I get > >> >>> > > > 156228 - about 3.75x less. > >> >>> > > > > >> >>> > > > diff --git > >> >>> > > > a/lucene/core/src/java/org/apache/lucene/util/fst/FST.java > >> >>> > > > b/lucene/core/src/java/org/apache/lucene/util/fst/FST.java > >> >>> > > > index f308f1a..ff99cc2 100644 > >> >>> > > > --- a/lucene/core/src/java/org/apache/lucene/util/fst/FST.java > >> >>> > > > +++ b/lucene/core/src/java/org/apache/lucene/util/fst/FST.java > >> >>> > > > @@ -647,7 +647,7 @@ public final class FST<T> implements > >> >>> > > > Accountable { > >> >>> > > > // array that may have holes in it so that we can address > >> >>> > > > the > >> >>> > > > arcs directly by label without > >> >>> > > > // binary search > >> >>> > > > int labelRange = nodeIn.arcs[nodeIn.numArcs - 1].label - > >> >>> > > > nodeIn.arcs[0].label + 1; > >> >>> > > > - boolean writeDirectly = labelRange > 0 && labelRange < > >> >>> > > > Builder.DIRECT_ARC_LOAD_FACTOR * nodeIn.numArcs; > >> >>> > > > + boolean writeDirectly = false; // labelRange > 0 && > >> >>> > > > labelRange > >> >>> > > > < Builder.DIRECT_ARC_LOAD_FACTOR * nodeIn.numArcs; > >> >>> > > > > >> >>> > > > //System.out.println("write int @pos=" + > >> >>> > > > (fixedArrayStart-4) + > >> >>> > > > " numArcs=" + nodeIn.numArcs); > >> >>> > > > // create the header > >> >>> > > > > >> >>> > > > On Mon, Jul 15, 2019 at 2:33 PM Michael Sokolov > >> >>> > > > <msoko...@gmail.com> wrote: > >> >>> > > > > > >> >>> > > > > OK, both LUCENE-8781 and LUCENE-8895 were introduced in 8.2.0. > >> >>> > > > > I see > >> >>> > > > > most of the other data sets report an increase more in the > >> >>> > > > > 10-15% > >> >>> > > > > range, which is expected. I'm curious what the makeup of that > >> >>> > > > > http > >> >>> > > > > logs data set is -- I guess it's HTTP logs :) Is the data > >> >>> > > > > public? > >> >>> > > > > > >> >>> > > > > > >> >>> > > > > On Mon, Jul 15, 2019 at 7:23 AM Ignacio Vera > >> >>> > > > > <iver...@gmail.com> wrote: > >> >>> > > > > > > >> >>> > > > > > The change to Lucene 8.2.0 snapshot was done on July 10th. > >> >>> > > > > > Previous to that the Lucene version was 8.1.0. > >> >>> > > > > > > >> >>> > > > > > On Mon, Jul 15, 2019 at 12:53 PM Michael Sokolov > >> >>> > > > > > <msoko...@gmail.com> wrote: > >> >>> > > > > >> > >> >>> > > > > >> Hmm that's possible, although the jump is bigger than > >> >>> > > > > >> anything I > >> >>> > > > > >> observed while testing. I assume these charts are building > >> >>> > > > > >> off of > >> >>> > > > > >> apache/master, or something close to that? If so, then the > >> >>> > > > > >> timing is > >> >>> > > > > >> off a bit. LUCENE-8781 was pushed quite a while before > >> >>> > > > > >> that, and then > >> >>> > > > > >> https://issues.apache.org/jira/browse/LUCENE-8895 which > >> >>> > > > > >> extended the > >> >>> > > > > >> encoding to be the default (not just for postings) was > >> >>> > > > > >> pushed on July > >> >>> > > > > >> 2 or so, but the chart shows a jump on July 10? > >> >>> > > > > >> > >> >>> > > > > >> On Mon, Jul 15, 2019 at 4:03 AM Ignacio Vera > >> >>> > > > > >> <iver...@gmail.com> wrote: > >> >>> > > > > >> > > >> >>> > > > > >> > Hi, > >> >>> > > > > >> > > >> >>> > > > > >> > We observed using a snapshot of Lucene 8.2 that there is > >> >>> > > > > >> > an increase of around 30% on the memory usage of > >> >>> > > > > >> > IndexReaders for some of the test datasets, for example: > >> >>> > > > > >> > > >> >>> > > > > >> > https://elasticsearch-benchmarks.elastic.co/#tracks/http-logs/nightly/default/30d > >> >>> > > > > >> > > >> >>> > > > > >> > We suspect this is due to this change: > >> >>> > > > > >> > https://issues.apache.org/jira/browse/LUCENE-8781 > >> >>> > > > > >> > > >> >>> > > > > >> > On Sun, Jul 14, 2019 at 7:10 AM David Smiley > >> >>> > > > > >> > <david.w.smi...@gmail.com> wrote: > >> >>> > > > > >> >> > >> >>> > > > > >> >> Since there won't be any 8.1.2 yet some issues got fixed > >> >>> > > > > >> >> for 8.1.2 and there is an 8.1.2 section in CHANGES.txt > >> >>> > > > > >> >> those issues might not be very noticeable to users that > >> >>> > > > > >> >> only look at the published HTML version (e.g. > >> >>> > > > > >> >> https://lucene.apache.org/solr/8_1_1/changes/Changes.html > >> >>> > > > > >> >> ). Maybe 8.1.2 should be integrated into 8.2.0 in > >> >>> > > > > >> >> CHANGES.txt? Despite this, I see at least one of those > >> >>> > > > > >> >> issues got into the curated release notes / highlights > >> >>> > > > > >> >> any way -- thanks Ignacio. > >> >>> > > > > >> >> > >> >>> > > > > >> >> ~ David Smiley > >> >>> > > > > >> >> Apache Lucene/Solr Search Developer > >> >>> > > > > >> >> http://www.linkedin.com/in/davidwsmiley > >> >>> > > > > >> >> > >> >>> > > > > >> >> > >> >>> > > > > >> >> On Fri, Jul 12, 2019 at 9:40 AM Jan Høydahl > >> >>> > > > > >> >> <jan....@cominvent.com> wrote: > >> >>> > > > > >> >>> > >> >>> > > > > >> >>> Please use HTTPS in the links to download pages. > >> >>> > > > > >> >>> > >> >>> > > > > >> >>> Jan Høydahl > >> >>> > > > > >> >>> > >> >>> > > > > >> >>> 12. jul. 2019 kl. 09:04 skrev Ignacio Vera > >> >>> > > > > >> >>> <iver...@gmail.com>: > >> >>> > > > > >> >>> > >> >>> > > > > >> >>> Ishan: I had a look into the issues and I have no > >> >>> > > > > >> >>> objections as far as they get properly reviewed if > >> >>> > > > > >> >>> possible. It will be good to commit the shortly so they > >> >>> > > > > >> >>> go through a few CI iterations in case something gets > >> >>> > > > > >> >>> broken. I am planning to build the first RC early next > >> >>> > > > > >> >>> week as there are no blockers for the release. > >> >>> > > > > >> >>> > >> >>> > > > > >> >>> Steve: Than you so much, I need to work on getting the > >> >>> > > > > >> >>> right permissions. > >> >>> > > > > >> >>> > >> >>> > > > > >> >>> Finally I wrote a draft for the release notes for > >> >>> > > > > >> >>> Lucene and Solr. It would be good if someone with more > >> >>> > > > > >> >>> experience in Solr can review/modify my attempt as it > >> >>> > > > > >> >>> is difficult for me to know which are the most > >> >>> > > > > >> >>> important bits. Here are the links to the drafts (not > >> >>> > > > > >> >>> they are in wiki, let me know if you have problems > >> >>> > > > > >> >>> accessing them): > >> >>> > > > > >> >>> > >> >>> > > > > >> >>> Lucene: > >> >>> > > > > >> >>> https://cwiki.apache.org/confluence/pages/resumedraft.action?draftId=120732808&draftShareId=cb366dc4-c136-4505-9c37-60bde5db2550&src=shareui&src.shareui.timestamp=1562914476369 > >> >>> > > > > >> >>> > >> >>> > > > > >> >>> Solr: > >> >>> > > > > >> >>> https://cwiki.apache.org/confluence/pages/resumedraft.action?draftId=120732972&draftShareId=5cace703-b80b-49c4-a07f-55b891683f90&src=shareui&src.shareui.timestamp=1562914529931 > >> >>> > > > > >> >>> > >> >>> > > > > >> >>> On Thu, Jul 11, 2019 at 6:36 PM Ishan Chattopadhyaya > >> >>> > > > > >> >>> <ichattopadhy...@gmail.com> wrote: > >> >>> > > > > >> >>>> > >> >>> > > > > >> >>>> Hi Ignacio, > >> >>> > > > > >> >>>> I wish to include two security bug fixes (not > >> >>> > > > > >> >>>> vulnerabilities, but feature regressions due to > >> >>> > > > > >> >>>> Authorization plugin), SOLR-13472 and SOLR-13619. I > >> >>> > > > > >> >>>> can commit both shortly, attempting to write a unit > >> >>> > > > > >> >>>> test for it (which is proving harder to do than > >> >>> > > > > >> >>>> reproducing, fixing and testing manually). Please let > >> >>> > > > > >> >>>> me know if you have any concerns. > >> >>> > > > > >> >>>> Regards, > >> >>> > > > > >> >>>> Ishan > >> >>> > > > > >> >>>> > >> >>> > > > > >> >>>> On Thu, 11 Jul, 2019, 9:12 PM Tomoko Uchida, > >> >>> > > > > >> >>>> <tomoko.uchida.1...@gmail.com> wrote: > >> >>> > > > > >> >>>>> > >> >>> > > > > >> >>>>> Hi Ignacio, > >> >>> > > > > >> >>>>> > >> >>> > > > > >> >>>>> LUCENE-8907 was fixed. (I have reverted a series of > >> >>> > > > > >> >>>>> commits which > >> >>> > > > > >> >>>>> cause backwards incompatibility on Lucene 8.x.) > >> >>> > > > > >> >>>>> Thank you for waiting for that! > >> >>> > > > > >> >>>>> > >> >>> > > > > >> >>>>> Tomoko > >> >>> > > > > >> >>>>> > >> >>> > > > > >> >>>>> 2019年7月11日(木) 22:44 Uwe Schindler <u...@thetaphi.de>: > >> >>> > > > > >> >>>>> > > >> >>> > > > > >> >>>>> > Hi, > >> >>> > > > > >> >>>>> > > >> >>> > > > > >> >>>>> > > >> >>> > > > > >> >>>>> > > >> >>> > > > > >> >>>>> > I enabled the policeman Jenkins Jobs for 8.2 branch. > >> >>> > > > > >> >>>>> > > >> >>> > > > > >> >>>>> > > >> >>> > > > > >> >>>>> > > >> >>> > > > > >> >>>>> > Uwe > >> >>> > > > > >> >>>>> > > >> >>> > > > > >> >>>>> > > >> >>> > > > > >> >>>>> > > >> >>> > > > > >> >>>>> > ----- > >> >>> > > > > >> >>>>> > > >> >>> > > > > >> >>>>> > Uwe Schindler > >> >>> > > > > >> >>>>> > > >> >>> > > > > >> >>>>> > Achterdiek 19, D-28357 Bremen > >> >>> > > > > >> >>>>> > > >> >>> > > > > >> >>>>> > https://www.thetaphi.de > >> >>> > > > > >> >>>>> > > >> >>> > > > > >> >>>>> > eMail: u...@thetaphi.de > >> >>> > > > > >> >>>>> > > >> >>> > > > > >> >>>>> > > >> >>> > > > > >> >>>>> > > >> >>> > > > > >> >>>>> > From: Ignacio Vera <iver...@gmail.com> > >> >>> > > > > >> >>>>> > Sent: Thursday, July 11, 2019 1:05 PM > >> >>> > > > > >> >>>>> > To: dev@lucene.apache.org > >> >>> > > > > >> >>>>> > Subject: Re: Lucene/Solr 8.2.0 > >> >>> > > > > >> >>>>> > > >> >>> > > > > >> >>>>> > > >> >>> > > > > >> >>>>> > > >> >>> > > > > >> >>>>> > Hi, > >> >>> > > > > >> >>>>> > > >> >>> > > > > >> >>>>> > > >> >>> > > > > >> >>>>> > > >> >>> > > > > >> >>>>> > The branch has been created, As a reminder, this > >> >>> > > > > >> >>>>> > branch is on feature freeze and only documentation > >> >>> > > > > >> >>>>> > or build patches should be committed. I will be > >> >>> > > > > >> >>>>> > waiting for LUCENE-8907 to start building the first > >> >>> > > > > >> >>>>> > release candidate. > >> >>> > > > > >> >>>>> > > >> >>> > > > > >> >>>>> > Let me know if there is any other blocker before we > >> >>> > > > > >> >>>>> > can start the release process. > >> >>> > > > > >> >>>>> > > >> >>> > > > > >> >>>>> > > >> >>> > > > > >> >>>>> > > >> >>> > > > > >> >>>>> > It seems I do not have the permissions to create > >> >>> > > > > >> >>>>> > the Jenkins jobs for this branch, maybe Steve can > >> >>> > > > > >> >>>>> > help here? > >> >>> > > > > >> >>>>> > > >> >>> > > > > >> >>>>> > > >> >>> > > > > >> >>>>> > > >> >>> > > > > >> >>>>> > Thanks, > >> >>> > > > > >> >>>>> > > >> >>> > > > > >> >>>>> > > >> >>> > > > > >> >>>>> > > >> >>> > > > > >> >>>>> > Ignacio > >> >>> > > > > >> >>>>> > > >> >>> > > > > >> >>>>> > > >> >>> > > > > >> >>>>> > > >> >>> > > > > >> >>>>> > On Thu, Jul 11, 2019 at 4:51 AM David Smiley > >> >>> > > > > >> >>>>> > <david.w.smi...@gmail.com> wrote: > >> >>> > > > > >> >>>>> > > >> >>> > > > > >> >>>>> > BTW for 8.2.0 I updated Solr's CHANGES.txt to split > >> >>> > > > > >> >>>>> > out issues that seemed to be Improvements that were > >> >>> > > > > >> >>>>> > not really New Features. > >> >>> > > > > >> >>>>> > > >> >>> > > > > >> >>>>> > > >> >>> > > > > >> >>>>> > ~ David Smiley > >> >>> > > > > >> >>>>> > > >> >>> > > > > >> >>>>> > Apache Lucene/Solr Search Developer > >> >>> > > > > >> >>>>> > > >> >>> > > > > >> >>>>> > http://www.linkedin.com/in/davidwsmiley > >> >>> > > > > >> >>>>> > > >> >>> > > > > >> >>>>> > > >> >>> > > > > >> >>>>> > > >> >>> > > > > >> >>>>> > > >> >>> > > > > >> >>>>> > > >> >>> > > > > >> >>>>> > On Wed, Jul 10, 2019 at 10:38 AM Ignacio Vera > >> >>> > > > > >> >>>>> > <iver...@gmail.com> wrote: > >> >>> > > > > >> >>>>> > > >> >>> > > > > >> >>>>> > Thanks Tomoko for taking care of that. > >> >>> > > > > >> >>>>> > > >> >>> > > > > >> >>>>> > > >> >>> > > > > >> >>>>> > > >> >>> > > > > >> >>>>> > On Wed, Jul 10, 2019 at 4:03 PM Đạt Cao Mạnh > >> >>> > > > > >> >>>>> > <caomanhdat...@gmail.com> wrote: > >> >>> > > > > >> >>>>> > > >> >>> > > > > >> >>>>> > Hi Ignacio, > >> >>> > > > > >> >>>>> > > >> >>> > > > > >> >>>>> > > >> >>> > > > > >> >>>>> > > >> >>> > > > > >> >>>>> > 8.1.2 bugfix release will cancelled. You can go > >> >>> > > > > >> >>>>> > ahead with 8.2 release. > >> >>> > > > > >> >>>>> > > >> >>> > > > > >> >>>>> > > >> >>> > > > > >> >>>>> > > >> >>> > > > > >> >>>>> > Thanks! > >> >>> > > > > >> >>>>> > > >> >>> > > > > >> >>>>> > > >> >>> > > > > >> >>>>> > > >> >>> > > > > >> >>>>> > On Wed, 10 Jul 2019 at 20:38, Tomoko Uchida > >> >>> > > > > >> >>>>> > <tomoko.uchida.1...@gmail.com> wrote: > >> >>> > > > > >> >>>>> > > >> >>> > > > > >> >>>>> > Hi, > >> >>> > > > > >> >>>>> > I opened a blocker issue a while ago for release > >> >>> > > > > >> >>>>> > 8.2: > >> >>> > > > > >> >>>>> > https://issues.apache.org/jira/browse/LUCENE-8907 > >> >>> > > > > >> >>>>> > > >> >>> > > > > >> >>>>> > Sorry about that, I noticed the backwards > >> >>> > > > > >> >>>>> > incompatibility we have to > >> >>> > > > > >> >>>>> > deal with today. If there are no objections, I will > >> >>> > > > > >> >>>>> > revert the all > >> >>> > > > > >> >>>>> > related commits from the branch_8x and 8_2 in a few > >> >>> > > > > >> >>>>> > days. > >> >>> > > > > >> >>>>> > > >> >>> > > > > >> >>>>> > Thanks, > >> >>> > > > > >> >>>>> > Tomoko > >> >>> > > > > >> >>>>> > > >> >>> > > > > >> >>>>> > 2019年7月10日(水) 22:02 Ignacio Vera > >> >>> > > > > >> >>>>> > <iver...@gmail.com>: > >> >>> > > > > >> >>>>> > > > >> >>> > > > > >> >>>>> > > Hi, > >> >>> > > > > >> >>>>> > > > >> >>> > > > > >> >>>>> > > All the issues listed above has been already > >> >>> > > > > >> >>>>> > > committed and I see no blockers for release 8.2. > >> >>> > > > > >> >>>>> > > I will cut the branch tomorrow around 10am CEST > >> >>> > > > > >> >>>>> > > and I will wait for the decision on the bug > >> >>> > > > > >> >>>>> > > release 8.1.2 to schedule the build of the first > >> >>> > > > > >> >>>>> > > release candidate. Please let us know if this is > >> >>> > > > > >> >>>>> > > troublesome for you. > >> >>> > > > > >> >>>>> > > > >> >>> > > > > >> >>>>> > > Thanks, > >> >>> > > > > >> >>>>> > > > >> >>> > > > > >> >>>>> > > Ignacio > >> >>> > > > > >> >>>>> > > > >> >>> > > > > >> >>>>> > > > >> >>> > > > > >> >>>>> > > On Tue, Jul 2, 2019 at 2:59 AM Joel Bernstein > >> >>> > > > > >> >>>>> > > <joels...@gmail.com> wrote: > >> >>> > > > > >> >>>>> > >> > >> >>> > > > > >> >>>>> > >> I've got one issue that I'd like to get in > >> >>> > > > > >> >>>>> > >> (https://issues.apache.org/jira/browse/SOLR-13589), > >> >>> > > > > >> >>>>> > >> which I should have wrapped up in a day or two. > >> >>> > > > > >> >>>>> > >> +1 for around July 10th. > >> >>> > > > > >> >>>>> > >> > >> >>> > > > > >> >>>>> > >> On Mon, Jul 1, 2019 at 5:14 PM Nicholas Knize > >> >>> > > > > >> >>>>> > >> <nkn...@gmail.com> wrote: > >> >>> > > > > >> >>>>> > >>> > >> >>> > > > > >> >>>>> > >>> +1 for starting the 8.2 release process. I > >> >>> > > > > >> >>>>> > >>> think it would be good to get the LUCENE-8632 > >> >>> > > > > >> >>>>> > >>> feature into 8.2 along with the BKD > >> >>> > > > > >> >>>>> > >>> improvements and changes in LUCENE-8888 and > >> >>> > > > > >> >>>>> > >>> LUCENE-8896 > >> >>> > > > > >> >>>>> > >>> > >> >>> > > > > >> >>>>> > >>> Nicholas Knize, Ph.D., GISP > >> >>> > > > > >> >>>>> > >>> Geospatial Software Guy | Elasticsearch > >> >>> > > > > >> >>>>> > >>> Apache Lucene PMC Member and Committer > >> >>> > > > > >> >>>>> > >>> nkn...@apache.org > >> >>> > > > > >> >>>>> > >>> > >> >>> > > > > >> >>>>> > >>> > >> >>> > > > > >> >>>>> > >>> On Wed, Jun 26, 2019 at 9:34 AM Ignacio Vera > >> >>> > > > > >> >>>>> > >>> <iver...@gmail.com> wrote: > >> >>> > > > > >> >>>>> > >>>> > >> >>> > > > > >> >>>>> > >>>> Hi all, > >> >>> > > > > >> >>>>> > >>>> > >> >>> > > > > >> >>>>> > >>>> 8.1 has been released on May 16th and we have > >> >>> > > > > >> >>>>> > >>>> new features, enhancements and fixes that are > >> >>> > > > > >> >>>>> > >>>> not released yet so I'd like to start thinking > >> >>> > > > > >> >>>>> > >>>> in releasing Lucene/Solr 8.2.0. > >> >>> > > > > >> >>>>> > >>>> > >> >>> > > > > >> >>>>> > >>>> I can create the 8.2 branch in two weeks time > >> >>> > > > > >> >>>>> > >>>> (around July 10th) and build the first RC by > >> >>> > > > > >> >>>>> > >>>> the end of that week if that works for > >> >>> > > > > >> >>>>> > >>>> everyone. Please let me know if there are bug > >> >>> > > > > >> >>>>> > >>>> fixes that needs to be fixed in 8.2 and might > >> >>> > > > > >> >>>>> > >>>> not be ready by then. > >> >>> > > > > >> >>>>> > >>>> > >> >>> > > > > >> >>>>> > >>>> Cheers, > >> >>> > > > > >> >>>>> > >>>> > >> >>> > > > > >> >>>>> > >>>> Ignacio > >> >>> > > > > >> >>>>> > > >> >>> > > > > >> >>>>> > --------------------------------------------------------------------- > >> >>> > > > > >> >>>>> > To unsubscribe, e-mail: > >> >>> > > > > >> >>>>> > dev-unsubscr...@lucene.apache.org > >> >>> > > > > >> >>>>> > For additional commands, e-mail: > >> >>> > > > > >> >>>>> > dev-h...@lucene.apache.org > >> >>> > > > > >> >>>>> > > >> >>> > > > > >> >>>>> > -- > >> >>> > > > > >> >>>>> > > >> >>> > > > > >> >>>>> > Best regards, > >> >>> > > > > >> >>>>> > > >> >>> > > > > >> >>>>> > Cao Mạnh Đạt > >> >>> > > > > >> >>>>> > > >> >>> > > > > >> >>>>> > E-mail: caomanhdat...@gmail.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 > >> >>> > > > > > >> >>> > > > > >> >>> > > > > >> >>> > > > -- > >> >>> > > > Adrien > >> >>> > > > > >> >>> > > > --------------------------------------------------------------------- > >> >>> > > > 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 > >> >>> > > > >> >>> > > >> >>> > > >> >>> > -- > >> >>> > Adrien > >> >>> > > >> >>> > --------------------------------------------------------------------- > >> >>> > 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 > >> > > > -- > Adrien > > --------------------------------------------------------------------- > 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
