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 <erickerick...@gmail.com> 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 <david.w.smi...@gmail.com> > 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 <jpou...@gmail.com> 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 <erickerick...@gmail.com> > 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: 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 > >
