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 <david.w.smi...@gmail.com>, 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 <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 > > >
