Let’s revive this email thread about Roadmap. With so many large initiatives going on, and the TLP split also, I think it makes perfect sense with a Roadmap. I know we’re not used to that kind of thing - we tend to just let things play out as it happens to land in various releases, but this time is special, and I think we’d benefit from more coordination. I don’t know how to enforce such coordination though, other than appealing to all committers to endorse the roadmap and respect it when they merge things. We may not be able to set a release date for 9.0 right now, but we may be able to define preconditions and scope certain features to 9.0 or 9.1 rather than 8.7 or 8.8 - that kind of coarse-grained decisions. We also may need a person that «owns» the Roadmap confluence page and actively promotes it, tries to keep it up to date and reminds the rest of us about its existence. A roadmap must NOT be a brake slowing us down, but a tool helping us avoid silly mistakes.
Jan > 5. jul. 2020 kl. 02:39 skrev Noble Paul <[email protected]>: > > I think the logical thing to do today is completely rip out all > autoscaling code as it exists today. > Let's deprecate that in 8.7 and build something for "assign-strategy". > Austoscaling , if required, should not be a part of Solr > > > > On Fri, Jul 3, 2020 at 5:48 PM Jan Høydahl <[email protected]> wrote: >> >> +1 >> >> Why don’t we make a Roadmap wiki page as Cassandra suggests, and indicate >> what major things needs to happen when. >> Perhaps if we can get the Solr TLP and git-split ball rolling as a pre-9.0 >> task, then perhaps 8.8 could be the last joint release (6.6, 7.7, 8.8 hehe)? >> That would enable Lucene to ship 9.0 without waiting for a ton of >> alpha-quality Solr features, and Solr could have its own Roadmap wiki. >> >> Jan >> >> 3. jul. 2020 kl. 09:19 skrev Dawid Weiss <[email protected]>: >> >> >>> 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. >> >> >> Adding a tarball is literally 3-5 lines of code (you add a task that builds >> a tarball or a zip file from the outputs of solr/packaging toDir task)... >> The bigger issue with gradle is that somebody has to step up and try to >> identify any other issues and/or missing bits when trying to do a full >> release cycle. >> >> D. >> >> > > > -- > ----------------------------------------------------- > Noble Paul > > --------------------------------------------------------------------- > To unsubscribe, e-mail: [email protected] > For additional commands, e-mail: [email protected] > --------------------------------------------------------------------- To unsubscribe, e-mail: [email protected] For additional commands, e-mail: [email protected]
