Solr 9.0?

classic Classic list List threaded Threaded
12 messages Options
Reply | Threaded
Open this post in threaded view
|

Solr 9.0?

Erick Erickson
What are people’s thoughts about Solr 9.0? It’d be a little faster than our recent cadence, the last two major releases were about 18 months after the one before and we released Solr 8.0 last March.

Besides the usual reasons, there are two drivers I can think of:

1> We can drop Java 8 compatibility.
2> We can migrate to exclusively use Gradle as the build system.

The Gradle build isn’t complete yet, although it’s maturing pretty quickly (and Dawid has yeoman’s duty!). My question isn’t so much “should we start the release process for Solr 9.0 next week” as it is “What milestones should we reach before starting the 9.0 release process?”

Maybe something as simple as “Start the 9.0 process a month after removing the ant components of the build system”.

And a reasonable answer at this point is “it’s way too early to even talk about it”.

Erick
---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: Solr 9.0?

Ishan Chattopadhyaya
I'd like to see the following in 9.0.

1. Make V2 API as default (deprecate V1),
2. Remove many non core functionality and move them into packages (consequently, support concept of first party packages),
3. Fix SolrCloud stability.

I think it is good to start planning, but, realistically, I see 9.0 at least 3-4 months out.

On Sun, 2 Feb, 2020, 8:05 PM Erick Erickson, <[hidden email]> wrote:
What are people’s thoughts about Solr 9.0? It’d be a little faster than our recent cadence, the last two major releases were about 18 months after the one before and we released Solr 8.0 last March.

Besides the usual reasons, there are two drivers I can think of:

1> We can drop Java 8 compatibility.
2> We can migrate to exclusively use Gradle as the build system.

The Gradle build isn’t complete yet, although it’s maturing pretty quickly (and Dawid has yeoman’s duty!). My question isn’t so much “should we start the release process for Solr 9.0 next week” as it is “What milestones should we reach before starting the 9.0 release process?”

Maybe something as simple as “Start the 9.0 process a month after removing the ant components of the build system”.

And a reasonable answer at this point is “it’s way too early to even talk about it”.

Erick
---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: Solr 9.0?

Erick Erickson
In reply to this post by Erick Erickson
bq. realistically, I see 9.0 at least 3-4 months out.

Probably, if we start planning now. Straw-man proposal: Let’s put up a JIRA for what we want to include in the 9.0 release with subtasks. No target date...

Although I’ll add that “Fix SolrCloud stability” is a never-ending goal. Admittedly we need to focus on it and we can argue how much improvement is “good enough” closer to the release date ;)



---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: Solr 9.0?

Jörn Franke
I think the goal „fix solr Cloud stability“ deserves some more thinking. Eg i would start with - how to measure it - because until now it is not measured. That means a benchmark that is close to what Solr cloud should be able to manage should be defined, eg we want to allow up to 50,000 cores or 100,000 collections with on average 3 replica and average size of 100 GB, ingestion rate scales linearly with the number of nodes (just random numbers to illustrate the point).Then maybe one can get from Apache foundation some cloud budget or similar to simulate the scenario for each release. Maybe one does not need to simulate that extreme but so that one can reliable interpolate from that one.

After that, I believe one can accept patches, redesign architecture (eg in form of Solr Improvement Proposals - SIP) etc.
maybe then the goal for 9.0 release could be that the benchmark is defined and can be executed on each release.

I know this is a lot of work, but this is the only way on how someone can make stability objectively measurable and also credible to the community.

Best regards

> Am 02.02.2020 um 22:08 schrieb Erick Erickson <[hidden email]>:
>
> bq. realistically, I see 9.0 at least 3-4 months out.
>
> Probably, if we start planning now. Straw-man proposal: Let’s put up a JIRA for what we want to include in the 9.0 release with subtasks. No target date...
>
> Although I’ll add that “Fix SolrCloud stability” is a never-ending goal. Admittedly we need to focus on it and we can argue how much improvement is “good enough” closer to the release date ;)
>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: [hidden email]
> For additional commands, e-mail: [hidden email]
>

---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: Solr 9.0?

Adrien Grand
In reply to this post by Erick Erickson
One Lucene issue I'd like to have in 9.0 is https://issues.apache.org/jira/browse/LUCENE-9047, which is about making our directory abstractions little-endian instead of big-endian. It would be breaking enough that it should be done in a major.

On Sun, Feb 2, 2020 at 3:35 PM Erick Erickson <[hidden email]> wrote:
What are people’s thoughts about Solr 9.0? It’d be a little faster than our recent cadence, the last two major releases were about 18 months after the one before and we released Solr 8.0 last March.

Besides the usual reasons, there are two drivers I can think of:

1> We can drop Java 8 compatibility.
2> We can migrate to exclusively use Gradle as the build system.

The Gradle build isn’t complete yet, although it’s maturing pretty quickly (and Dawid has yeoman’s duty!). My question isn’t so much “should we start the release process for Solr 9.0 next week” as it is “What milestones should we reach before starting the 9.0 release process?”

Maybe something as simple as “Start the 9.0 process a month after removing the ant components of the build system”.

And a reasonable answer at this point is “it’s way too early to even talk about it”.

Erick
---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]



--
Adrien
Reply | Threaded
Open this post in threaded view
|

Re: Solr 9.0?

david.w.smiley@gmail.com
We can use JIRA to annotate what we want to do for 9x.  I know from experience it can be a bit aspirational and that's okay.  Eventually reality will set in and we'll remove the fix-version accordingly.

~ David Smiley
Apache Lucene/Solr Search Developer


On Sun, Feb 2, 2020 at 4:46 PM Adrien Grand <[hidden email]> wrote:
One Lucene issue I'd like to have in 9.0 is https://issues.apache.org/jira/browse/LUCENE-9047, which is about making our directory abstractions little-endian instead of big-endian. It would be breaking enough that it should be done in a major.

On Sun, Feb 2, 2020 at 3:35 PM Erick Erickson <[hidden email]> wrote:
What are people’s thoughts about Solr 9.0? It’d be a little faster than our recent cadence, the last two major releases were about 18 months after the one before and we released Solr 8.0 last March.

Besides the usual reasons, there are two drivers I can think of:

1> We can drop Java 8 compatibility.
2> We can migrate to exclusively use Gradle as the build system.

The Gradle build isn’t complete yet, although it’s maturing pretty quickly (and Dawid has yeoman’s duty!). My question isn’t so much “should we start the release process for Solr 9.0 next week” as it is “What milestones should we reach before starting the 9.0 release process?”

Maybe something as simple as “Start the 9.0 process a month after removing the ant components of the build system”.

And a reasonable answer at this point is “it’s way too early to even talk about it”.

Erick
---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]



--
Adrien
Reply | Threaded
Open this post in threaded view
|

Re: Solr 9.0?

Erick Erickson
Are you thinking individual JIRAs just with a “fix version” of 9.0 or a single task-list with them all? One task list seems easier to follow….

> On Feb 2, 2020, at 4:48 PM, David Smiley <[hidden email]> wrote:
>
> We can use JIRA to annotate what we want to do for 9x.  I know from experience it can be a bit aspirational and that's okay.  Eventually reality will set in and we'll remove the fix-version accordingly.
>
> ~ David Smiley
> Apache Lucene/Solr Search Developer
> http://www.linkedin.com/in/davidwsmiley
>
>
> On Sun, Feb 2, 2020 at 4:46 PM Adrien Grand <[hidden email]> wrote:
> One Lucene issue I'd like to have in 9.0 is https://issues.apache.org/jira/browse/LUCENE-9047, which is about making our directory abstractions little-endian instead of big-endian. It would be breaking enough that it should be done in a major.
>
> On Sun, Feb 2, 2020 at 3:35 PM Erick Erickson <[hidden email]> wrote:
> What are people’s thoughts about Solr 9.0? It’d be a little faster than our recent cadence, the last two major releases were about 18 months after the one before and we released Solr 8.0 last March.
>
> Besides the usual reasons, there are two drivers I can think of:
>
> 1> We can drop Java 8 compatibility.
> 2> We can migrate to exclusively use Gradle as the build system.
>
> The Gradle build isn’t complete yet, although it’s maturing pretty quickly (and Dawid has yeoman’s duty!). My question isn’t so much “should we start the release process for Solr 9.0 next week” as it is “What milestones should we reach before starting the 9.0 release process?”
>
> Maybe something as simple as “Start the 9.0 process a month after removing the ant components of the build system”.
>
> And a reasonable answer at this point is “it’s way too early to even talk about it”.
>
> Erick
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: [hidden email]
> For additional commands, e-mail: [hidden email]
>
>
>
> --
> Adrien


---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: Solr 9.0?

david.w.smiley@gmail.com
Yes "fix version". By "a single task list" do you mean one issue with sub-tasks?  Definitely "-1" from me as it seems like a huge misuse of JIRA when the concept of a version is already present.  I think issues can't be multi-level as well so it'd rule out any bigger items that already have sub-tasks.

Here are all LUCENE/SOLR issues that are not resolved with a fix version of "master (9.0)":

There are many -- 134.  As to be expected, many are aspirational and we'll never get to by 9 or ever, and of course sometimes a contributor sets the version prematurely.  I think we could further refine this by considering the assignee, and assign or unassign ourselves as we volunteer to get stuff done.

Speaking of which, maybe we could make "fix version" only settable by us committers?

~ David Smiley
Apache Lucene/Solr Search Developer


On Sun, Feb 2, 2020 at 5:42 PM Erick Erickson <[hidden email]> wrote:
Are you thinking individual JIRAs just with a “fix version” of 9.0 or a single task-list with them all? One task list seems easier to follow….

> On Feb 2, 2020, at 4:48 PM, David Smiley <[hidden email]> wrote:
>
> We can use JIRA to annotate what we want to do for 9x.  I know from experience it can be a bit aspirational and that's okay.  Eventually reality will set in and we'll remove the fix-version accordingly.
>
> ~ David Smiley
> Apache Lucene/Solr Search Developer
> http://www.linkedin.com/in/davidwsmiley
>
>
> On Sun, Feb 2, 2020 at 4:46 PM Adrien Grand <[hidden email]> wrote:
> One Lucene issue I'd like to have in 9.0 is https://issues.apache.org/jira/browse/LUCENE-9047, which is about making our directory abstractions little-endian instead of big-endian. It would be breaking enough that it should be done in a major.
>
> On Sun, Feb 2, 2020 at 3:35 PM Erick Erickson <[hidden email]> wrote:
> What are people’s thoughts about Solr 9.0? It’d be a little faster than our recent cadence, the last two major releases were about 18 months after the one before and we released Solr 8.0 last March.
>
> Besides the usual reasons, there are two drivers I can think of:
>
> 1> We can drop Java 8 compatibility.
> 2> We can migrate to exclusively use Gradle as the build system.
>
> The Gradle build isn’t complete yet, although it’s maturing pretty quickly (and Dawid has yeoman’s duty!). My question isn’t so much “should we start the release process for Solr 9.0 next week” as it is “What milestones should we reach before starting the 9.0 release process?”
>
> Maybe something as simple as “Start the 9.0 process a month after removing the ant components of the build system”.
>
> And a reasonable answer at this point is “it’s way too early to even talk about it”.
>
> Erick
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: [hidden email]
> For additional commands, e-mail: [hidden email]
>
>
>
> --
> Adrien


---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: Solr 9.0?

Erick Erickson
In reply to this post by david.w.smiley@gmail.com
bq. it seems like a huge misuse of JIRA

I disagree, but not enough to bikeshed. I’m looking for the most efficient way to get the scope of what we want to include in 9.0 defined.

Wading through 134 issues is tedious, WDYT about a “future” tag? Once we go through those 134 issues and change the ones we know we won’t get to the process will be more tractable. We could make the ones we want to include in 9.0 “blockers”.

Point is mostly to get a way to measure progress. The last thing I want to do is wade through 134 issues making a judgement call on each one multiple times between now and release.



> On Feb 2, 2020, at 4:48 PM, David Smiley <[hidden email]> wrote:
>
> We can use JIRA to annotate what we want to do for 9x.  I know from experience it can be a bit aspirational and that's okay.  Eventually reality will set in and we'll remove the fix-version accordingly.
>
> ~ David Smiley
> Apache Lucene/Solr Search Developer
> http://www.linkedin.com/in/davidwsmiley
>
>
> On Sun, Feb 2, 2020 at 4:46 PM Adrien Grand <[hidden email]> wrote:
> One Lucene issue I'd like to have in 9.0 is https://issues.apache.org/jira/browse/LUCENE-9047, which is about making our directory abstractions little-endian instead of big-endian. It would be breaking enough that it should be done in a major.
>
> On Sun, Feb 2, 2020 at 3:35 PM Erick Erickson <[hidden email]> wrote:
> What are people’s thoughts about Solr 9.0? It’d be a little faster than our recent cadence, the last two major releases were about 18 months after the one before and we released Solr 8.0 last March.
>
> Besides the usual reasons, there are two drivers I can think of:
>
> 1> We can drop Java 8 compatibility.
> 2> We can migrate to exclusively use Gradle as the build system.
>
> The Gradle build isn’t complete yet, although it’s maturing pretty quickly (and Dawid has yeoman’s duty!). My question isn’t so much “should we start the release process for Solr 9.0 next week” as it is “What milestones should we reach before starting the 9.0 release process?”
>
> Maybe something as simple as “Start the 9.0 process a month after removing the ant components of the build system”.
>
> And a reasonable answer at this point is “it’s way too early to even talk about it”.
>
> Erick
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: [hidden email]
> For additional commands, e-mail: [hidden email]
>
>
>
> --
> Adrien


---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: Solr 9.0?

david.w.smiley@gmail.com
I suspect your motivation for something other than a JIRA query is that developing a JIRA query can take a few minutes whereas a simple tag to search is less.  But just a tag is less powerful and is, I think, redundant with the existing JIRA metadata.  Tags need to be maintained; if we do a simply tag this release then we need to clean them up after release since it'd get in the way at a subsequent release.  And think of it this way: many of us have already been in effect curating our TODO for 9.x list using fix-version.

This JIRA query matches 54 issues.  I edited the previous query to list only issues that are either assigned or that are priority of Blocker:

https://issues.apache.org/jira/issues/?jql=project%20in%20(LUCENE%2C%20SOLR)%20AND%20fixVersion%20%3D%20%22master%20(9.0)%22%20AND%20resolution%20is%20EMPTY%20and%20(assignee%20is%20not%20EMPTY%20OR%20priority%20%3D%20Blocker)%20ORDER%20BY%20priority%20DESC%2C%20updated%20DESC

Feel free to just refer back to this email to click this link so that you needn't waste time writing a JIRA query.  In addition, maybe we could make this easier in a release "developer docs" page.

~ David Smiley
Apache Lucene/Solr Search Developer


On Mon, Feb 3, 2020 at 7:38 AM Erick Erickson <[hidden email]> wrote:
bq. it seems like a huge misuse of JIRA

I disagree, but not enough to bikeshed. I’m looking for the most efficient way to get the scope of what we want to include in 9.0 defined.

Wading through 134 issues is tedious, WDYT about a “future” tag? Once we go through those 134 issues and change the ones we know we won’t get to the process will be more tractable. We could make the ones we want to include in 9.0 “blockers”.

Point is mostly to get a way to measure progress. The last thing I want to do is wade through 134 issues making a judgement call on each one multiple times between now and release.



> On Feb 2, 2020, at 4:48 PM, David Smiley <[hidden email]> wrote:
>
> We can use JIRA to annotate what we want to do for 9x.  I know from experience it can be a bit aspirational and that's okay.  Eventually reality will set in and we'll remove the fix-version accordingly.
>
> ~ David Smiley
> Apache Lucene/Solr Search Developer
> http://www.linkedin.com/in/davidwsmiley
>
>
> On Sun, Feb 2, 2020 at 4:46 PM Adrien Grand <[hidden email]> wrote:
> One Lucene issue I'd like to have in 9.0 is https://issues.apache.org/jira/browse/LUCENE-9047, which is about making our directory abstractions little-endian instead of big-endian. It would be breaking enough that it should be done in a major.
>
> On Sun, Feb 2, 2020 at 3:35 PM Erick Erickson <[hidden email]> wrote:
> What are people’s thoughts about Solr 9.0? It’d be a little faster than our recent cadence, the last two major releases were about 18 months after the one before and we released Solr 8.0 last March.
>
> Besides the usual reasons, there are two drivers I can think of:
>
> 1> We can drop Java 8 compatibility.
> 2> We can migrate to exclusively use Gradle as the build system.
>
> The Gradle build isn’t complete yet, although it’s maturing pretty quickly (and Dawid has yeoman’s duty!). My question isn’t so much “should we start the release process for Solr 9.0 next week” as it is “What milestones should we reach before starting the 9.0 release process?”
>
> Maybe something as simple as “Start the 9.0 process a month after removing the ant components of the build system”.
>
> And a reasonable answer at this point is “it’s way too early to even talk about it”.
>
> Erick
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: [hidden email]
> For additional commands, e-mail: [hidden email]
>
>
>
> --
> Adrien


---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: Solr 9.0?

Cassandra Targett
Our Jira is connected to Confluence and supports some pretty nice integration features. Instead of trying to organize 100s of issues in Jira, we could make a "9.0 Planning" page in Confluence and use that integration to show us issue status along our primary goals.

This integration is primarily driven from queries of Jira, so instead of a page that’s a huge list of issues, we could use a combination of the Fix Version field and labels (or any other combination of query-able data elements) to make queries, charts, and/or reports for each goal we intend to try to accomplish.

For example, if we want “Improve SolrCloud stability” to be something we achieve before the release, we identify the Jira issues that define how we plan to meet that goal and make a query for them. Then we set up a section of the 9.0 Planning page to show the progress (either a list of issues, or a chart, or both). Then every time anyone wants to know where we’re at, we just go to the page and the status is automatically updated. If we’re not making progress on a goal, we can choose to defer it or any of the issues in it (change the fix version/label) at any time and the page stays up to date with our current plan.


Since the cwiki spaces are separated between Lucene and Solr, we could have 2 pages for this planning that link to each other (if we want).

Just a suggestion, but I think users who like to try to plan for new major versions would love to see what we’re planning in an easier way, and I think it would really help us stay organized.

Cassandra 
On Feb 3, 2020, 7:24 AM -0600, David Smiley <[hidden email]>, wrote:
I suspect your motivation for something other than a JIRA query is that developing a JIRA query can take a few minutes whereas a simple tag to search is less.  But just a tag is less powerful and is, I think, redundant with the existing JIRA metadata.  Tags need to be maintained; if we do a simply tag this release then we need to clean them up after release since it'd get in the way at a subsequent release.  And think of it this way: many of us have already been in effect curating our TODO for 9.x list using fix-version.

This JIRA query matches 54 issues.  I edited the previous query to list only issues that are either assigned or that are priority of Blocker:

https://issues.apache.org/jira/issues/?jql=project%20in%20(LUCENE%2C%20SOLR)%20AND%20fixVersion%20%3D%20%22master%20(9.0)%22%20AND%20resolution%20is%20EMPTY%20and%20(assignee%20is%20not%20EMPTY%20OR%20priority%20%3D%20Blocker)%20ORDER%20BY%20priority%20DESC%2C%20updated%20DESC

Feel free to just refer back to this email to click this link so that you needn't waste time writing a JIRA query.  In addition, maybe we could make this easier in a release "developer docs" page.

~ David Smiley
Apache Lucene/Solr Search Developer


On Mon, Feb 3, 2020 at 7:38 AM Erick Erickson <[hidden email]> wrote:
bq. it seems like a huge misuse of JIRA

I disagree, but not enough to bikeshed. I’m looking for the most efficient way to get the scope of what we want to include in 9.0 defined.

Wading through 134 issues is tedious, WDYT about a “future” tag? Once we go through those 134 issues and change the ones we know we won’t get to the process will be more tractable. We could make the ones we want to include in 9.0 “blockers”.

Point is mostly to get a way to measure progress. The last thing I want to do is wade through 134 issues making a judgement call on each one multiple times between now and release.



> On Feb 2, 2020, at 4:48 PM, David Smiley <[hidden email]> wrote:
>
> We can use JIRA to annotate what we want to do for 9x.  I know from experience it can be a bit aspirational and that's okay.  Eventually reality will set in and we'll remove the fix-version accordingly.
>
> ~ David Smiley
> Apache Lucene/Solr Search Developer
> http://www.linkedin.com/in/davidwsmiley
>
>
> On Sun, Feb 2, 2020 at 4:46 PM Adrien Grand <[hidden email]> wrote:
> One Lucene issue I'd like to have in 9.0 is https://issues.apache.org/jira/browse/LUCENE-9047, which is about making our directory abstractions little-endian instead of big-endian. It would be breaking enough that it should be done in a major.
>
> On Sun, Feb 2, 2020 at 3:35 PM Erick Erickson <[hidden email]> wrote:
> What are people’s thoughts about Solr 9.0? It’d be a little faster than our recent cadence, the last two major releases were about 18 months after the one before and we released Solr 8.0 last March.
>
> Besides the usual reasons, there are two drivers I can think of:
>
> 1> We can drop Java 8 compatibility.
> 2> We can migrate to exclusively use Gradle as the build system.
>
> The Gradle build isn’t complete yet, although it’s maturing pretty quickly (and Dawid has yeoman’s duty!). My question isn’t so much “should we start the release process for Solr 9.0 next week” as it is “What milestones should we reach before starting the 9.0 release process?”
>
> Maybe something as simple as “Start the 9.0 process a month after removing the ant components of the build system”.
>
> And a reasonable answer at this point is “it’s way too early to even talk about it”.
>
> Erick
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: [hidden email]
> For additional commands, e-mail: [hidden email]
>
>
>
> --
> Adrien


---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: Solr 9.0?

Erick Erickson
Oooh, nice idea!

> On Feb 3, 2020, at 10:00 AM, Cassandra Targett <[hidden email]> wrote:
>
> Our Jira is connected to Confluence and supports some pretty nice integration features. Instead of trying to organize 100s of issues in Jira, we could make a "9.0 Planning" page in Confluence and use that integration to show us issue status along our primary goals.
>
> This integration is primarily driven from queries of Jira, so instead of a page that’s a huge list of issues, we could use a combination of the Fix Version field and labels (or any other combination of query-able data elements) to make queries, charts, and/or reports for each goal we intend to try to accomplish.
>
> For example, if we want “Improve SolrCloud stability” to be something we achieve before the release, we identify the Jira issues that define how we plan to meet that goal and make a query for them. Then we set up a section of the 9.0 Planning page to show the progress (either a list of issues, or a chart, or both). Then every time anyone wants to know where we’re at, we just go to the page and the status is automatically updated. If we’re not making progress on a goal, we can choose to defer it or any of the issues in it (change the fix version/label) at any time and the page stays up to date with our current plan.
>
> More info on the integration points: https://confluence.atlassian.com/conf71/use-jira-applications-and-confluence-together-979423628.html
>
> Since the cwiki spaces are separated between Lucene and Solr, we could have 2 pages for this planning that link to each other (if we want).
>
> Just a suggestion, but I think users who like to try to plan for new major versions would love to see what we’re planning in an easier way, and I think it would really help us stay organized.
>
> Cassandra
> On Feb 3, 2020, 7:24 AM -0600, David Smiley <[hidden email]>, wrote:
>> I suspect your motivation for something other than a JIRA query is that developing a JIRA query can take a few minutes whereas a simple tag to search is less.  But just a tag is less powerful and is, I think, redundant with the existing JIRA metadata.  Tags need to be maintained; if we do a simply tag this release then we need to clean them up after release since it'd get in the way at a subsequent release.  And think of it this way: many of us have already been in effect curating our TODO for 9.x list using fix-version.
>>
>> This JIRA query matches 54 issues.  I edited the previous query to list only issues that are either assigned or that are priority of Blocker:
>>
>> https://issues.apache.org/jira/issues/?jql=project%20in%20(LUCENE%2C%20SOLR)%20AND%20fixVersion%20%3D%20%22master%20(9.0)%22%20AND%20resolution%20is%20EMPTY%20and%20(assignee%20is%20not%20EMPTY%20OR%20priority%20%3D%20Blocker)%20ORDER%20BY%20priority%20DESC%2C%20updated%20DESC
>>
>> Feel free to just refer back to this email to click this link so that you needn't waste time writing a JIRA query.  In addition, maybe we could make this easier in a release "developer docs" page.
>>
>> ~ David Smiley
>> Apache Lucene/Solr Search Developer
>> http://www.linkedin.com/in/davidwsmiley
>>
>>
>> On Mon, Feb 3, 2020 at 7:38 AM Erick Erickson <[hidden email]> wrote:
>> bq. it seems like a huge misuse of JIRA
>>
>> I disagree, but not enough to bikeshed. I’m looking for the most efficient way to get the scope of what we want to include in 9.0 defined.
>>
>> Wading through 134 issues is tedious, WDYT about a “future” tag? Once we go through those 134 issues and change the ones we know we won’t get to the process will be more tractable. We could make the ones we want to include in 9.0 “blockers”.
>>
>> Point is mostly to get a way to measure progress. The last thing I want to do is wade through 134 issues making a judgement call on each one multiple times between now and release.
>>
>>
>>
>> > On Feb 2, 2020, at 4:48 PM, David Smiley <[hidden email]> wrote:
>> >
>> > We can use JIRA to annotate what we want to do for 9x.  I know from experience it can be a bit aspirational and that's okay.  Eventually reality will set in and we'll remove the fix-version accordingly.
>> >
>> > ~ David Smiley
>> > Apache Lucene/Solr Search Developer
>> > http://www.linkedin.com/in/davidwsmiley
>> >
>> >
>> > On Sun, Feb 2, 2020 at 4:46 PM Adrien Grand <[hidden email]> wrote:
>> > One Lucene issue I'd like to have in 9.0 is https://issues.apache.org/jira/browse/LUCENE-9047, which is about making our directory abstractions little-endian instead of big-endian. It would be breaking enough that it should be done in a major.
>> >
>> > On Sun, Feb 2, 2020 at 3:35 PM Erick Erickson <[hidden email]> wrote:
>> > What are people’s thoughts about Solr 9.0? It’d be a little faster than our recent cadence, the last two major releases were about 18 months after the one before and we released Solr 8.0 last March.
>> >
>> > Besides the usual reasons, there are two drivers I can think of:
>> >
>> > 1> We can drop Java 8 compatibility.
>> > 2> We can migrate to exclusively use Gradle as the build system.
>> >
>> > The Gradle build isn’t complete yet, although it’s maturing pretty quickly (and Dawid has yeoman’s duty!). My question isn’t so much “should we start the release process for Solr 9.0 next week” as it is “What milestones should we reach before starting the 9.0 release process?”
>> >
>> > Maybe something as simple as “Start the 9.0 process a month after removing the ant components of the build system”.
>> >
>> > And a reasonable answer at this point is “it’s way too early to even talk about it”.
>> >
>> > Erick
>> > ---------------------------------------------------------------------
>> > To unsubscribe, e-mail: [hidden email]
>> > For additional commands, e-mail: [hidden email]
>> >
>> >
>> >
>> > --
>> > Adrien
>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: [hidden email]
>> For additional commands, e-mail: [hidden email]
>>


---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]