I opened a PR that adds a commit that wipes the content of branch_8x on the lucene-solr repository, including the GitHub workflow, and adds a simple README that explains that 8.11 was the last minor release of the 8.x series. I didn't add anything about the fact that there might be (or not) more Solr-specific 8.x releases, since it made the message too complicated. We can still edit this README if/when we do something about it.
https://github.com/apache/lucene-solr/pull/2616 On Tue, Nov 23, 2021 at 5:17 PM Ishan Chattopadhyaya < ichattopadhy...@gmail.com> wrote: > > Makes me feel it would be OK to handle this cleanup asynchronously to > the 9.0 release. > +1. It is unreasonable to hold up the 9.0 release for this. > > On Tue, Nov 23, 2021 at 9:03 PM Michael Sokolov <msoko...@gmail.com> > wrote: > >> +1 to remove all content and leave behind a README in 8.x and 7.x, and >> it sounds like adding the .asf..yaml file could even prevent further >> commits? >> >> I hope there weren't any consequences of having a few unintended >> commits in the 7x branch. Makes me feel it would be OK to handle this >> cleanup asynchronously to the 9.0 release. >> >> On Tue, Nov 23, 2021 at 10:14 AM Uwe Schindler <u...@thetaphi.de> wrote: >> > >> > Hi, >> > >> > I checked a bit: branch_7x is also still alive and has some accidental >> commits in it. So maybe we should do the same there. >> > >> > In general if we change this, don't forget to change github workflows: >> https://github.com/apache/lucene-solr/blob/master/.github/workflows/ant.yml >> > >> > Side note: I am missing the .asf.yaml file in the master branch of old >> repo. Where is this information stored? This file was there also to protect >> branches from writing (at least in github): >> https://cwiki.apache.org/confluence/display/INFRA/Git+-+.asf.yaml+features#Git.asf.yamlfeatures-BranchProtection >> > >> > Uwe >> > >> > ----- >> > Uwe Schindler >> > Achterdiek 19, D-28357 Bremen >> > https://www.thetaphi.de >> > eMail: u...@thetaphi.de >> > >> > > -----Original Message----- >> > > From: Adrien Grand <jpou...@gmail.com> >> > > Sent: Tuesday, November 23, 2021 2:02 PM >> > > To: Lucene Dev <dev@lucene.apache.org> >> > > Subject: Re: What should we do of branch_8x? >> > > >> > > It looks like there is now general agreement on removing branch_8x? >> > > >> > > I wonder if we should actually remove it, which is prone to >> > > re-creating the branch by mistake, vs. replacing the content of the >> > > repository with a README that says that this branch is no longer under >> > > development like we did for the `master` branch. >> > > >> > > On Mon, Nov 22, 2021 at 5:09 PM Jan Høydahl <jan....@cominvent.com> >> > > wrote: >> > > > >> > > > +1 to remove / lock branch_8x in the lucene-solr repo, i.e. there >> will not be an >> > > 8.12 release by Lucene PMC. >> > > > >> > > > Whether Solr needs to release an 8.12 from own repos or not can be >> > > discussed in dev@solr if/when needed. So far there is only loose >> talk, and I >> > > think Solr PMC's energy should be devoted to the Solr 9.0 release. >> > > > >> > > > Jan >> > > > >> > > > > 22. nov. 2021 kl. 08:28 skrev Atri Sharma <a...@apache.org>: >> > > > > >> > > > > +1, agree with Uwe. >> > > > > >> > > > > On Mon, Nov 22, 2021 at 12:39 PM Ishan Chattopadhyaya >> > > > > <ichattopadhy...@gmail.com> wrote: >> > > > >> >> > > > >> +1 to Uwe's suggestion >> > > > >> >> > > > >> On Mon, 22 Nov, 2021, 11:13 am Gus Heck, <gus.h...@gmail.com> >> > > wrote: >> > > > >>> >> > > > >>> +1 to uwe's suggestion >> > > > >>> >> > > > >>> On Sun, Nov 21, 2021 at 10:42 PM Noble Paul < >> noble.p...@gmail.com> >> > > wrote: >> > > > >>>> >> > > > >>>> I think this is a reasonable suggestion Uwe. >> > > > >>>> >> > > > >>>> - We don't need to bring Gradle to 8.x >> > > > >>>> - We can release 8.12 from a fork of 8.11. >> > > > >>>> - we don't need to keep the Lucene source files in that >> branch. We can >> > > nuke it and just keep the Lucene binaries >> > > > >>>> >> > > > >>>> On Mon, Nov 22, 2021, 8:49 AM Uwe Schindler <u...@thetaphi.de> >> > > wrote: >> > > > >>>>> >> > > > >>>>> Hi, >> > > > >>>>> >> > > > >>>>> If this is really needed, I'd propose the following: >> > > > >>>>> >> > > > >>>>> - fork the branch_8_11 to solr's repo >> > > > >>>>> - delete all subdirectories below lucene, keep common-build >> and other >> > > stuff. >> > > > >>>>> - add a single ivy.xml there that refers to all lucene jars >> of 8.11.x >> > > (latest) >> > > > >>>>> - adapt solr's "copy-lucene-jars" ant task to copy the ivy >> output dir >> > > > >>>>> - delete the lucene stuff from release wizard. >> > > > >>>>> >> > > > >>>>> This is quick and easy. Adapting Gradle for a minor release >> is too hard. >> > > > >>>>> >> > > > >>>>> Am 21. November 2021 21:34:40 UTC schrieb Noble Paul >> > > <noble.p...@gmail.com>: >> > > > >>>>>> >> > > > >>>>>> All Solr users using 8x and they will need some time to get >> > > comfortable with 9x . So, there is a good chance we may need to >> release an >> > > 8.12 based on Lucene 8.11 >> > > > >>>>>> >> > > > >>>>>> On Mon, Nov 22, 2021, 8:22 AM Adrien Grand < >> jpou...@gmail.com> >> > > wrote: >> > > > >>>>>>> >> > > > >>>>>>> +1 to making branch_8x read-only as Uwe suggested >> > > > >>>>>>> >> > > > >>>>>>> I think Uwe's other point is also important: if we ever >> wanted to do a >> > > Solr 8.12, it'd probably be a better option to fork the 8.11 branch >> than to try to >> > > reuse branch_8x. So we don't need to tie the decision about what we >> want to >> > > do with branch_8x with future plans around an 8.12 release? >> > > > >>>>>>> >> > > > >>>>>>> On Sun, Nov 21, 2021 at 7:48 PM Uwe Schindler >> > > <u...@thetaphi.de> wrote: >> > > > >>>>>>>> >> > > > >>>>>>>> This is of course all possible, but: WHY the heck do this? >> > > > >>>>>>>> >> > > > >>>>>>>> >> > > > >>>>>>>> >> > > > >>>>>>>> Lucene 9.0 will come out likely very soon. After that just >> update the >> > > gradle file of Solr main and remove the temporary repository (better >> comment >> > > it out). After that adapt some changes and release Solr 9.0. >> > > > >>>>>>>> >> > > > >>>>>>>> >> > > > >>>>>>>> >> > > > >>>>>>>> From that point on both projects have a clear split point >> and >> > > everybody can make sure that the backwards compatibility is handled >> > > according to project’s needs. >> > > > >>>>>>>> >> > > > >>>>>>>> >> > > > >>>>>>>> >> > > > >>>>>>>> If the Solr 9.0 release is a intermediary point (not all >> deprecations >> > > removed), release Solr 10.0 four months later, who cares? Solr 9.0 >> will be the >> > > release with many new features and Java 11 as minimum requirement. >> > > > >>>>>>>> >> > > > >>>>>>>> >> > > > >>>>>>>> >> > > > >>>>>>>> I would really, really not start and fuck up the release >> process for >> > > 8.x! Why not release 8.11.1 soon, if you have any changes in Solr to >> do? Why >> > > do this release needs to be called 8.12? It is just a version number, >> so why the >> > > heck this big issues? I won’t think that Solr will add any major >> features before >> > > Solr 9. So what is your exact problem? >> > > > >>>>>>>> >> > > > >>>>>>>> >> > > > >>>>>>>> >> > > > >>>>>>>> Sorry, but this discussion is complete nonsense. Its just >> version >> > > numbers and some hick-hack between two parties that disagree. Keep >> calm and >> > > don’t try to make it overcomplicated! >> > > > >>>>>>>> >> > > > >>>>>>>> >> > > > >>>>>>>> >> > > > >>>>>>>> I never said that we should kill or delete branch_8x. It >> can stay >> > > there forever. I just suggested to make it read-only and add a note. >> Unless >> > > there’s really a need to do some 8.12 release (in which case, I’d >> fork 8.11 >> > > branch and move Lucene) I see no reason to act and fuck up the >> repositories of >> > > both projects which have now a very clear state. >> > > > >>>>>>>> >> > > > >>>>>>>> >> > > > >>>>>>>> >> > > > >>>>>>>> Uwe >> > > > >>>>>>>> >> > > > >>>>>>>> >> > > > >>>>>>>> >> > > > >>>>>>>> ----- >> > > > >>>>>>>> >> > > > >>>>>>>> Uwe Schindler >> > > > >>>>>>>> >> > > > >>>>>>>> Achterdiek 19, D-28357 Bremen >> > > > >>>>>>>> >> > > > >>>>>>>> https://www.thetaphi.de >> > > > >>>>>>>> >> > > > >>>>>>>> eMail: u...@thetaphi.de >> > > > >>>>>>>> >> > > > >>>>>>>> >> > > > >>>>>>>> >> > > > >>>>>>>> From: Gus Heck <gus.h...@gmail.com> >> > > > >>>>>>>> Sent: Sunday, November 21, 2021 5:05 PM >> > > > >>>>>>>> To: dev <dev@lucene.apache.org> >> > > > >>>>>>>> Subject: Re: What should we do of branch_8x? >> > > > >>>>>>>> >> > > > >>>>>>>> >> > > > >>>>>>>> >> > > > >>>>>>>> Release of Solr 8.12 It should require the current >> lucene-solr 8.x >> > > branch to remove the lucene bits and declare a dependency on lucene >> 8.11 >> > > lucene, that bit shouldn't be too hard if done soon... and the >> release process for >> > > 8.x would not publish a lucene artifact which is likely the harder >> bit. I think the >> > > option should be open assuming someone is willing to do that work.What >> > > should not be an option is any further lucene releases on 8.x and >> I'd be very >> > > leery of any attempt to consume lucene 9.0 on Solr 8.x >> > > > >>>>>>>> >> > > > >>>>>>>> >> > > > >>>>>>>> >> > > > >>>>>>>> The Lucene guarantees are irrelevant unless someone >> contemplates >> > > releasing an 8.12 lucene, and I really think that would require a >> positive vote >> > > from the Lucene PMC (which sounds very unlikely since I see fingers >> twitching >> > > over the -1 holsters there :) ) >> > > > >>>>>>>> >> > > > >>>>>>>> >> > > > >>>>>>>> >> > > > >>>>>>>> So while I don't favor deleting the entire solr 8.x branch >> I think it's >> > > now fine to remove lucene from it. >> > > > >>>>>>>> >> > > > >>>>>>>> >> > > > >>>>>>>> >> > > > >>>>>>>> To make things pretty, one could push the 8.x branch to >> the solr >> > > repo AFTER lucene is removed, but that sounds like busy work unless >> there is >> > > some formal or financial need to close the old repo. They are now >> fully >> > > separate projects and what solr does with the non-lucene bits is not >> a concern >> > > to lucene pmc (though almost all of us are on both committees of >> course, but >> > > hat wearing etc..) >> > > > >>>>>>>> >> > > > >>>>>>>> >> > > > >>>>>>>> >> > > > >>>>>>>> On Sun, Nov 21, 2021 at 8:43 AM Robert Muir >> > > <rcm...@gmail.com> wrote: >> > > > >>>>>>>> >> > > > >>>>>>>> I dunno, this seems really crazy to me. Splitting out solr >> into its >> > > > >>>>>>>> own repository and allowing it to be released >> independently from >> > > > >>>>>>>> lucene has already been done, lots of work :) Why not just >> move >> > > > >>>>>>>> forwards? >> > > > >>>>>>>> >> > > > >>>>>>>> On Sun, Nov 21, 2021 at 8:16 AM Ishan Chattopadhyaya >> > > > >>>>>>>> <ichattopadhy...@gmail.com> wrote: >> > > > >>>>>>>>> >> > > > >>>>>>>>> >> > > > >>>>>>>>> >> > > > >>>>>>>>> On Sun, 21 Nov, 2021, 6:31 pm Robert Muir, < >> rcm...@gmail.com> >> > > wrote: >> > > > >>>>>>>>>> >> > > > >>>>>>>>>> Sorry, I just don't understand the implications of what >> you are >> > > suggesting. >> > > > >>>>>>>>>> >> > > > >>>>>>>>>> The code in question is lucene+solr combined, and the >> build >> > > system and >> > > > >>>>>>>>>> packaging and everything only knows how to do that. So >> are you >> > > forking >> > > > >>>>>>>>>> all the lucene code into the solr repo too? >> > > > >>>>>>>>> >> > > > >>>>>>>>> >> > > > >>>>>>>>> Need to split it up and remove the Lucene code from there >> in >> > > order to be able to release Solr independently. We can do so later >> (I'm currently >> > > on travel), if/when needed. >> > > > >>>>>>>>>> >> > > > >>>>>>>>>> >> > > > >>>>>>>>>> I don't really understand your need to have a branch_8x. >> we can >> > > nuke >> > > > >>>>>>>>>> it, and you can do any of this from a branch_8_11 some >> other >> > > day, no? >> > > > >>>>>>>>> >> > > > >>>>>>>>> >> > > > >>>>>>>>> I guess we can, just don't know the divergence. Just to >> be on the >> > > safer side, don't want to lose access to the branch_8x over a weekend >> before I >> > > or persons more knowledgeable (on the differences between the >> branches) >> > > than I get a chance to review the situation. Hence, I just copied the >> branch >> > > there for the moment. >> > > > >>>>>>>>>> >> > > > >>>>>>>>>> >> > > > >>>>>>>>>> On Sun, Nov 21, 2021 at 7:57 AM Ishan Chattopadhyaya >> > > > >>>>>>>>>> <ichattopadhy...@gmail.com> wrote: >> > > > >>>>>>>>>>> >> > > > >>>>>>>>>>>> I don't think the solr PMC should issue Lucene 8.12 >> either. >> > > > >>>>>>>>>>> I never expressed any intention of doing so. Besides, >> is it even >> > > possible (ASF policies wise)? >> > > > >>>>>>>>>>> >> > > > >>>>>>>>>>> This is a weekend, and I feel bad holding up the 9.0 >> release >> > > (since this is a blocker). Solr PMC can decide later on Solr's >> releases, and hence >> > > I'm going to copy this branch_8x over to Solr repo's >> "lucene-solr/branch_8x" >> > > branch. >> > > > >>>>>>>>>>> >> > > > >>>>>>>>>>> >> > > > >>>>>>>>>>> On Sun, Nov 21, 2021 at 6:14 PM Robert Muir >> > > <rcm...@gmail.com> wrote: >> > > > >>>>>>>>>>>> >> > > > >>>>>>>>>>>> I don't think the solr PMC should issue Lucene 8.12 >> either. >> > > > >>>>>>>>>>>> >> > > > >>>>>>>>>>>> On Sun, Nov 21, 2021 at 7:42 AM Ishan Chattopadhyaya >> > > > >>>>>>>>>>>> <ichattopadhy...@gmail.com> wrote: >> > > > >>>>>>>>>>>>> >> > > > >>>>>>>>>>>>> Sounds good, Rob. Should I copy over the branch_8x to >> the >> > > solr repo until we have further clarity on the course of action to be >> taken with >> > > Solr releases? >> > > > >>>>>>>>>>>>> >> > > > >>>>>>>>>>>>> On Sun, 21 Nov, 2021, 6:10 pm Robert Muir, >> > > <rcm...@gmail.com> wrote: >> > > > >>>>>>>>>>>>>> >> > > > >>>>>>>>>>>>>> Nope, it isn't crazy. I am trying to ensure the >> backwards >> > > > >>>>>>>>>>>>>> compatibility that we have is on solid, sustainable >> footing >> > > before we >> > > > >>>>>>>>>>>>>> release a new version promising double the back >> compat. >> > > > >>>>>>>>>>>>>> >> > > > >>>>>>>>>>>>>> On Sun, Nov 21, 2021 at 7:37 AM Ishan Chattopadhyaya >> > > > >>>>>>>>>>>>>> <ichattopadhy...@gmail.com> wrote: >> > > > >>>>>>>>>>>>>>> >> > > > >>>>>>>>>>>>>>> Solr doesn't have backward compatability tests, only >> > > Lucene has. >> > > > >>>>>>>>>>>>>>> >> > > > >>>>>>>>>>>>>>> That's why I proposed leaving the door open for a >> Solr 8.12 >> > > release based on already released 8.11 Lucene and not releasing any >> further 8.x >> > > minor version release of Lucene. >> > > > >>>>>>>>>>>>>>> >> > > > >>>>>>>>>>>>>>> As I said, if that's problematic to do on branch_8x >> of >> > > lucene-solr, then we can do so in the solr repo. If some urgent >> action to nuke >> > > the branch is to be taken, please give some time to explore >> alternatives that >> > > affect Solr's developement. >> > > > >>>>>>>>>>>>>>> >> > > > >>>>>>>>>>>>>>> Holding up Lucene 9.0 release for removal of >> branch_8x is >> > > lunacy, not the continued existence of this branch in the shared >> repo, since a >> > > future course of action should be deliberated upon before nuking the >> branch. >> > > > >>>>>>>>>>>>>>> >> > > > >>>>>>>>>>>>>>> On Sun, 21 Nov, 2021, 5:34 pm Uwe Schindler, >> > > <u...@thetaphi.de> wrote: >> > > > >>>>>>>>>>>>>>>> >> > > > >>>>>>>>>>>>>>>> Hi, >> > > > >>>>>>>>>>>>>>>> >> > > > >>>>>>>>>>>>>>>> I fully agree with Robert here. >> > > > >>>>>>>>>>>>>>>> >> > > > >>>>>>>>>>>>>>>> I originally sent the question about branch_8x >> because of >> > > this. Once we released Lucene 9.0 wen can't release 8.12, because the >> index file >> > > format will be brand marked as originating from 8.12 then, which 9.0 >> will >> > > refuse to read. >> > > > >>>>>>>>>>>>>>>> >> > > > >>>>>>>>>>>>>>>> We can only release 8.11.x which is not allowed to >> have >> > > index format changes and minor version numbers are not persisted. >> > > > >>>>>>>>>>>>>>>> >> > > > >>>>>>>>>>>>>>>> So -1 to release a 8.12 an time in future. If you >> still want >> > > one, hold 9.0 release and add precautions for this. >> > > > >>>>>>>>>>>>>>>> >> > > > >>>>>>>>>>>>>>>> Imho. Let's stop releasing 8.12 or later for >> Lucene/Solr and >> > > just add Bugfixes. This also applies to Solr. Later this is >> decoupled, so Solr >> > > 9.1234 may use Lucene 10.4711. >> > > > >>>>>>>>>>>>>>>> >> > > > >>>>>>>>>>>>>>>> As said before: let's close branch 8.x and add >> protection >> > > to it in GitHub. Anybox may merge Bugfixes directly from Solr or >> Lucene main I >> > > to branch_8_11. I see no problem. Just no index changes! >> > > > >>>>>>>>>>>>>>>> >> > > > >>>>>>>>>>>>>>>> Uwe >> > > > >>>>>>>>>>>>>>>> >> > > > >>>>>>>>>>>>>>>> Am 21. November 2021 11:51:34 UTC schrieb Robert >> > > Muir <rcm...@gmail.com>: >> > > > >>>>>>>>>>>>>>>>> >> > > > >>>>>>>>>>>>>>>>> I gave my technical justification: our backwards >> > > compatibility testing >> > > > >>>>>>>>>>>>>>>>> doesnt work this way. 9.0 can't have guaranteed >> back >> > > compat with >> > > > >>>>>>>>>>>>>>>>> versions coming in the future. This is lunacy. >> > > > >>>>>>>>>>>>>>>>> >> > > > >>>>>>>>>>>>>>>>> On Sun, Nov 21, 2021 at 6:30 AM Ishan >> Chattopadhyaya >> > > > >>>>>>>>>>>>>>>>> <ichattopadhy...@gmail.com> wrote: >> > > > >>>>>>>>>>>>>>>>>> >> > > > >>>>>>>>>>>>>>>>>> >> > > > >>>>>>>>>>>>>>>>>> >> https://www.apache.org/foundation/voting.html#Veto >> > > > >>>>>>>>>>>>>>>>>> >> > > > >>>>>>>>>>>>>>>>>> "To prevent vetoes from being used capriciously, >> the >> > > voter must provide with the veto a *technical justification* showing >> why the >> > > change is bad (opens a security exposure, negatively affects >> performance, etc. ). >> > > A veto without a justification is invalid and has no weight." >> > > > >>>>>>>>>>>>>>>>>> >> > > > >>>>>>>>>>>>>>>>>> On Sun, 21 Nov, 2021, 3:30 pm Robert Muir, >> > > <rcm...@gmail.com> wrote: >> > > > >>>>>>>>>>>>>>>>>>> >> > > > >>>>>>>>>>>>>>>>>>> >> > > > >>>>>>>>>>>>>>>>>>> I think we should remove this branch. >> > > > >>>>>>>>>>>>>>>>>>> >> > > > >>>>>>>>>>>>>>>>>>> personally, i'll probably -1 any commit to it. >> I'll see if i >> > > can >> > > > >>>>>>>>>>>>>>>>>>> automate such an email response with a gmail >> rule. >> > > > >>>>>>>>>>>>>>>>>>> >> > > > >>>>>>>>>>>>>>>>>>> we already released lucene 9.0, we can't change >> > > backwards >> > > > >>>>>>>>>>>>>>>>>>> compatibility for some 8.12, same old story, >> lets move >> > > on people. >> > > > >>>>>>>>>>>>>>>>>>> >> > > > >>>>>>>>>>>>>>>>>>> On Sat, Nov 20, 2021 at 9:29 AM Adrien Grand >> > > <jpou...@gmail.com> wrote: >> > > > >>>>>>>>>>>>>>>>>>>> >> > > > >>>>>>>>>>>>>>>>>>>> >> > > > >>>>>>>>>>>>>>>>>>>> Uwe brought up the question on a the vote >> thread: >> > > we are not going to do a 8.12 release, so what should we do of >> branch_8x? >> > > > >>>>>>>>>>>>>>>>>>> >> > > > >>>>>>>>>>>>>>>>>>> ________________________________ >> > > > >>>>>>>>>>>>>>>>>>> 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 >> > > > >>>>>>>>>>>>>>>>> >> > > > >>>>>>>>>>>>>>>> -- >> > > > >>>>>>>>>>>>>>>> Uwe Schindler >> > > > >>>>>>>>>>>>>>>> Achterdiek 19, 28357 Bremen >> > > > >>>>>>>>>>>>>>>> https://www.thetaphi.de >> > > > >>>>>>>> >> > > > >>>>>>>> >> --------------------------------------------------------------------- >> > > > >>>>>>>> To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org >> > > > >>>>>>>> For additional commands, e-mail: >> dev-h...@lucene.apache.org >> > > > >>>>>>>> >> > > > >>>>>>>> >> > > > >>>>>>>> >> > > > >>>>>>>> -- >> > > > >>>>>>>> >> > > > >>>>>>>> http://www.needhamsoftware.com (work) >> > > > >>>>>>>> >> > > > >>>>>>>> http://www.the111shift.com (play) >> > > > >>>>>>> >> > > > >>>>>>> >> > > > >>>>>>> >> > > > >>>>>>> -- >> > > > >>>>>>> Adrien >> > > > >>>>> >> > > > >>>>> -- >> > > > >>>>> Uwe Schindler >> > > > >>>>> Achterdiek 19, 28357 Bremen >> > > > >>>>> https://www.thetaphi.de >> > > > >>> >> > > > >>> >> > > > >>> >> > > > >>> -- >> > > > >>> http://www.needhamsoftware.com (work) >> > > > >>> http://www.the111shift.com (play) >> > > > > >> > > > > -- >> > > > > Regards, >> > > > > >> > > > > Atri >> > > > > Apache Concerted >> > > > > >> > > > > >> --------------------------------------------------------------------- >> > > > > 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
