Re: 8.7 Release
As the branch has been cut, I deleted 8.6 jobs and created 8.7 jobs on the ASF Jenkins: https://ci-builds.apache.org/job/Lucene/. On Tue, Oct 13, 2020 at 6:16 PM Adrien Grand wrote: > This sounds good to me, thank you! > > On Tue, Oct 13, 2020 at 6:06 PM Atri Sharma wrote: > >> I will start the first build candidate on upcoming Monday. This is my >> first release so fingers crossed :) >> >> On Tue, Oct 13, 2020 at 7:01 PM Adrien Grand wrote: >> > >> > Thanks Atri. Do you know when you will start the first build candidate >> as well? We had been doing some planning around Ishan's initial suggestion >> of cutting the branch on September 20th, so as this is getting delayed I'm >> trying to get a sense of whether the release would likely be out in the >> next two weeks. >> > >> > On Tue, Oct 13, 2020 at 12:10 PM Atri Sharma wrote: >> >> >> >> Adrien, >> >> >> >> Sorry for the delay in response. >> >> >> >> I will cut the branch this Friday morning (IST). >> >> >> >> Atri >> >> >> >> On Tue, 13 Oct 2020 at 05:43, Houston Putman >> wrote: >> >>> >> >>> Adrien, I plan on merging SOLR-14907 to master and 8x tomorrow. If >> you would mind waiting to cut 8.7 until then, I would appreciate it. >> >>> >> >>> - Houston >> >>> >> >>> On Mon, Oct 12, 2020 at 4:59 AM Adrien Grand >> wrote: >> >> Shall we move forward with 8.7 now that 8.6.3 is out? >> >> On Tue, Sep 22, 2020 at 9:32 PM Atri Sharma wrote: >> > >> > I plan to cut the branch on 30th September. >> > >> > On Wed, 23 Sep 2020 at 00:51, Cassandra Targett < >> casstarg...@gmail.com> wrote: >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> Atri, >> >> >> >> >> >> >> >> >> >> >> >> Just so I understand your plans, when you say you are planning to >> start the process at the end of this month, you mean you intend to create >> the branch around Oct 1? No pressure, I ask only because Ishan’s original >> mail mentioned cutting the branch this week and I just wanted to have a >> clearer sense of your timeline. >> >> >> >> >> >> >> >> >> >> >> >> Thanks, >> >> >> >> >> >> Cassandra >> >> >> >> >> >> >> >> >> >> On Sep 15, 2020, 11:53 PM -0500, Atri Sharma , >> wrote: >> >> >> >> >> >> >> >> >> >> I was planning to start the process end of this month. >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> On Wed, 16 Sep 2020 at 04:07, Gus Heck wrote: >> >> >> >> >> >>> >> >>> >> >>> Unless it somehow got lost in a spam filter somewhere, I don't >> think we have set a target date for the release yet? (roadmap says autumn >> 2020 which technically doesn't begin until the solstice on the 21st :) ) >> >>> >> >>> >> >>> >> >>> >> >>> Hoping that I might still get the Advanced Query parser in first, >> but that's a much bigger prospect than these two tickets. >> >>> >> >>> >> >>> >> >>> >> >>> >> >>> >> >>> >> >>> >> >>> >> >>> -Gus >> >>> >> >>> >> >>> >> >>> >> >>> >> >>> >> >>> >> >>> >> >>> >> >>> On Tue, Sep 15, 2020 at 5:29 PM Erik Hatcher < >> erik.hatc...@gmail.com> wrote: >> >>> >> >>> >> >> >> Unless there are objections, I'm gonna get >> https://issues.apache.org/jira/browse/SOLR-14799 into 8.7 as well. >> >> >> >> >> Erik >> >> >> >> >> >> >> >> >> >> >> On Sep 14, 2020, at 10:06 AM, Christine Poerschke (BLOOMBERG/ >> LONDON) wrote: >> >> >> >> >> >> >> >> >> >> With a view towards including it in the release, I'd appreciate >> input on the >> >> >> >> >> https://issues.apache.org/jira/browse/SOLR-14828 >> >> >> >> >> >> solrj logging tweak if anyone has a moment? >> >> >> >> >> Thanks, >> >> >> Christine >> >> >> >> >> >> >> >> >> >> >> >> From: dev@lucene.apache.org At: 08/20/20 22:48:39 >> >> >> To: dev@lucene.apache.org >> >> >> Subject: Re: 8.7 Release >> >> >> >> >> >> >> >> >> >> >> >> Also, we should try to respect the stuff we have put on the >> roadmap (Which includes me getting a patch up for SIP-9 much sooner rather >> than even a little later!) >> >> >> >>
Re: JIRAs with user facing changes
+1, we should strive to be consistent in the user-facing APIs / configs / UX. I’m wondering if there’s any support in Jira for conditional fields, so that when you create a Jira issue if you tick off an option “Affects the UX?” it opens a mandatory text field to describe the changes. > On 16 Oct 2020, at 20:19, Noble Paul wrote: > > Hi, > I'm proposing a process for every ticket which has a user facing > change. The changes could be > > * A new command/end point > * A new request parameter > * A configuration (solr.xml, clusterprops.json, or any other file in ZK) > * A new file (part of file) in ZK > * A new file in file system > > I may have missed some. > > Please ensure that the changes are described in the description of the > JIRA. This gives a heads up to other committers that a new user facing > change is being introduced. > > Solr's UX is inconsistent & hard and the reason is that we all make > user-facing changes without enough review. Of course we add ref guide > documentation. But, it is not done until it is too late. The intent to > make a change should be made clear well in advance so that we get > early feedback. Other committers often see the changes pretty late and > at this point it is too late to change because of backward > incompatibility. > > > -- > - > Noble Paul > > - > 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: Approach towards solving split package issues?
Hi, please review LUCENE-9318, this refactors backward-codecs module (packages are renamed). I'm going to merge it into the master after waiting a week or so if there is no objection/feedback. Tomoko 2020年9月3日(木) 22:35 Tomoko Uchida : > I also opened SOLR-14826 as the placeholder. I'm not fully sure of its > priority but at least Alexandre expressed an interest in fixing it for > Solr, thanks. > If there is someone who wants to take the ownership, please feel free to > join. I will leave it there until LUCENE-9499 is done anyway. > > > > 2020年9月3日(木) 0:12 Tomoko Uchida : > >> I opened LUCENE-9499 as the umbrella. >> I set "Fix version" to 9.0 - means once we make a commit on it, this will >> be a blocker for release 9.0.0. (I don't think the changes should be >> delivered across two major releases; all changes have to be out at once in >> a major release.) If there are any objections or concerns, please leave >> comments. For now I have no idea about the total volume of changes or >> technical obstacles that have to be handled. >> >> About Solr - do we really need to fix split packages? Solr is a server >> app, the benefits seem to be smaller than Lucene (a library) for me. I'd >> like to hear opinions/thoughts from others. >> >> Tomoko >> >> >> 2020年9月2日(水) 9:05 Gus Heck : >> >>> +1 to fixing and +1 to doing it in a major release. >>> >>> On Tue, Sep 1, 2020 at 4:32 PM Adrien Grand wrote: >>> +1 Changing packages of many classes should be done in a major. On Tue, Sep 1, 2020 at 5:50 PM Tomoko Uchida < tomoko.uchida.1...@gmail.com> wrote: > Just to make sure, could I confirm "when the changes will be out"... > Resolving split package issues should break backward compatibility > (changing package names and moving classes from one module to another > modules). So we have just two options, we can have these changes only on > major releases - 9.0.0 or 10.0.0; we cannot release such changes at minor > versions. Is that correct? > > Tomoko > > > 2020年9月1日(火) 22:08 Tomoko Uchida : > >> > As I recall one issue was around where to put analysis packages? >> >> It's LUCENE-9317. I had worked on it before, you can see what changes >> will be needed for analyzers-common (and core). >> >> >> 2020年9月1日(火) 22:00 Michael Sokolov : >> >>> I'm in favor - there may be some difficult choices though. As I >>> recall >>> one issue was around where to put analysis packages? I forget the >>> details, but there was some pretty strong feeling that you should >>> have >>> a functioning system with core only. However some basic analysis >>> tools >>> are required for that, while most of our analyzers and so on are in a >>> separate analysis module. Perhaps we will need to move some basic >>> analyzers out of com.amazon.lucene.analysis? Or the reverse - move >>> all >>> the analysis code into the analysis module and acknowledge that it is >>> a fundamental dependency (more essential than core, really). >>> >>> On Tue, Sep 1, 2020 at 8:26 AM Tomoko Uchida >>> wrote: >>> > >>> > yes, Jigsaw was on my mind too... >>> > >>> > > why not go ahead and try to clean it up right away? >>> > >>> > > So a strong +1 to clean this up! >>> > >>> > OK, maybe I should open two issues, one for Lucene and one for >>> Solr, and link existing wip issues to them. >>> > Once we start it, these will be blockers for 9.0.0 release I >>> believe (for now I have no idea about the volume of the changes or >>> technical obstacles). Are there any objections or comments? >>> > >>> > >>> > 2020年9月1日(火) 19:34 Uwe Schindler : >>> >> >>> >> Hi, >>> >> >>> >> The biggest issue is that split packages make migrating to the >>> Java 9 module system impossible. It's not allowed to have same package >>> name >>> (with classes) in different JAR files. >>> >> >>> >> Some of those require to open up visibility of classes. Some >>> split packages issues were done because of package private access, >>> which is >>> very bad between JAR files. This also affects the test framework, >>> although >>> this is not such a big deal (I would exclude that for now), because you >>> would never run UNIT tests inside a module system, only integration >>> tests. >>> >> >>> >> So a strong +1 to clean this up! >>> >> Uwe >>> >> >>> >> - >>> >> Uwe Schindler >>> >> Achterdiek 19, D-28357 Bremen >>> >> https://www.thetaphi.de >>> >> eMail: u...@thetaphi.de >>> >> >>> >> > -Original Message- >>> >> > From: Dawid Weiss >>> >> > Sent: Tuesday, September 1, 2020 9:22 AM >>> >> > To: Lucene Dev >>> >> > Subject: Re: Approach towards solving split package issues? >>> >> > >>> >> > This is a big headache for many things. I would
Re: JIRAs with user facing changes
I don't think we have such an option in JIRA. However, we can add a similar item to the checklist in github On Sat, Oct 17, 2020 at 6:43 PM Andrzej Białecki wrote: > > +1, we should strive to be consistent in the user-facing APIs / configs / UX. > > I’m wondering if there’s any support in Jira for conditional fields, so that > when you create a Jira issue if you tick off an option “Affects the UX?” it > opens a mandatory text field to describe the changes. > > > > On 16 Oct 2020, at 20:19, Noble Paul wrote: > > > > Hi, > > I'm proposing a process for every ticket which has a user facing > > change. The changes could be > > > > * A new command/end point > > * A new request parameter > > * A configuration (solr.xml, clusterprops.json, or any other file in ZK) > > * A new file (part of file) in ZK > > * A new file in file system > > > > I may have missed some. > > > > Please ensure that the changes are described in the description of the > > JIRA. This gives a heads up to other committers that a new user facing > > change is being introduced. > > > > Solr's UX is inconsistent & hard and the reason is that we all make > > user-facing changes without enough review. Of course we add ref guide > > documentation. But, it is not done until it is too late. The intent to > > make a change should be made clear well in advance so that we get > > early feedback. Other committers often see the changes pretty late and > > at this point it is too late to change because of backward > > incompatibility. > > > > > > -- > > - > > Noble Paul > > > > - > > 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 > -- - Noble Paul - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
