Oooh, nice idea! > On Feb 3, 2020, at 10:00 AM, Cassandra Targett <casstarg...@gmail.com> 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 <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 >>
--------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
