I went ahead and merged the above PR, which wiped out the comment of branch_8x: https://github.com/apache/lucene-solr/tree/branch_8x.
I also removed the 8.x builds on Apache Jenkins (which were only disabled until now). On Tue, Nov 23, 2021 at 7:52 PM Adrien Grand <jpou...@gmail.com> wrote: > 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 > -- Adrien
