I’ll throw out the same suggestion I made when we had the same conversation
about 6 months ago - we should make a 9.0 Roadmap wiki page, use it to write
down & agree on goals, then add labels to Jira issues so we can go back to the
wiki page and add queries which automatically query Jira and return issues and
their status for each goal area. This use case is at least half the reason why
a deep integration between Confluence and Jira exists.
On Jul 2, 2020, 1:39 PM -0500, Erick Erickson <erickerick...@gmail.com>, wrote:
> There’s value IMO in having the discussion in one place rather than having to
> search all of the JIRA tickets...
>
> > On Jul 2, 2020, at 2:30 PM, Gus Heck <gus.h...@gmail.com> wrote:
> >
> > Looking at
> > https://issues.apache.org/jira/projects/SOLR?selectedItem=com.atlassian.jira.jira-projects-plugin%3Arelease-page&status=unreleased
> > maybe this is as simple as having one more field on our issues...
> > Currently fix version denotes when something got fixed, perhaps a "target
> > version" field could indicate when we want to fix it by. Then we just need
> > a tag in jira and perhaps a branch.
> >
> > Alternately (or maybe additionally) we could make a "board" if that's
> > easier to monitor.
> >
> > On Thu, Jul 2, 2020 at 2:02 PM Gus Heck <gus.h...@gmail.com> wrote:
> > Jira typically has features for designating what's in a release....
> >
> > On Thu, Jul 2, 2020 at 1:55 PM Erick Erickson <erickerick...@gmail.com>
> > wrote:
> > I totally expect some things to bubble up when we try to release with
> > Gradle, the tarball being one. I don’t think that’s a very big issue, but
> > if you have lots of “not very big” issues they do add up.
> >
> > That said, yeah, I do think it’s time to start getting a handle on 9.0.
> > Pulling Ant out of the build system is another possibility.
> >
> > Solr as a TLP? Or is that Solr 10? Or does it even have to be as of a major
> > release?
> >
> > Sound like a Wiki page or some such to me…
> >
> > Erick
> >
> > > On Jul 2, 2020, at 1:07 PM, Andrzej Białecki <a...@getopt.org> wrote:
> > >
> > > Autoscaling is another big item, but I think we have to put it into 9x,
> > > it’s a critical (and critically broken) functionality. We’re making some
> > > progress with Ilan and Noble so I’m cautiously optimistic.
> > >
> > > > On 2 Jul 2020, at 18:58, Gus Heck <gus.h...@gmail.com> wrote:
> > > >
> > > > Should we have one?
> > > >
> > > > With 9x having java 11 and gradle migrations on the dev side, and about
> > > > to have a significant round of deprecations/removals and migrations to
> > > > plugin for things such as CDCR, DIH etc (see
> > > > https://issues.apache.org/jira/browse/SOLR-13442 and
> > > > https://issues.apache.org/jira/browse/SOLR-14022) some of which may(?)
> > > > need a replacement (i.e. CDCR?) or ways ot easily re-enable (i.e.
> > > > streaming) before 9x is able to be released. Plus there's been talk of
> > > > a revamped UI...
> > > >
> > > > I'm worried that there is a danger that 9x will continue to diverge and
> > > > pick up major changes, but always have something big in progress and
> > > > never be able to release.
> > > >
> > > > Perhaps we should attempt to put a box around the things that need to
> > > > happen for 9x, and begin targeting any larger projects that come up at
> > > > 10x? Among other things the gradle work probably can't be complete
> > > > until someone has gone through a release using it. (I don't think we
> > > > build the tarballs in gradle yet for example, unless that got added
> > > > recently)
> > > >
> > > > -Gus
> > > >
> > > > --
> > > > http://www.needhamsoftware.com (work)
> > > > http://www.the111shift.com (play)
> > >
> >
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
> > For additional commands, e-mail: dev-h...@lucene.apache.org
> >
> >
> >
> > --
> > http://www.needhamsoftware.com (work)
> > http://www.the111shift.com (play)
> >
> >
> > --
> > http://www.needhamsoftware.com (work)
> > http://www.the111shift.com (play)
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
> For additional commands, e-mail: dev-h...@lucene.apache.org
>
