Cool, since I brought it up, I can volunteer to help manage the page. We should get jira issue links in there wherever possible. Do we want to build an initial list and have some sort of Proposed/Planned workflow so readers can have confidence (or appropriate lack of confidence) in what they see there? voting on things seems like too much but maybe folks who care watch the page, and if something is on there for a week without objection it can be called accepted? If a discussion starts here it can be marked "Considering" so... something like this:
4 states: Proposed, Considering, Planned, Rejected Workflow like this: Proposed -------(no objection 1 wk) --> Planned Proposed -------(discussion)----------> Considering Considering ----(agreement) ----------> Planned Considering ----(deferred) -----------> Proposed (later release) Considering ----(unsuitable) ---------> Rejected Considering ----(promoted) -----------> Proposed (earlier release) Planned --------(difficulty found) ---> Considering Anything in "Considering" should have an active dev list thread, and if it didn't happen on the list it didn't happen :). Any of that (or differences of opinion during Considering) can be overridden by a formal vote of course -Gus On Tue, Aug 11, 2020 at 10:29 AM Ishan Chattopadhyaya < [email protected]> wrote: > I've created a placeholder document here: > https://cwiki.apache.org/confluence/display/SOLR/Roadmap > Let us put in all our items there. > > On Tue, Aug 11, 2020 at 4:45 PM Jan Høydahl <[email protected]> wrote: > >> 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] >> >> -- http://www.needhamsoftware.com (work) http://www.the111shift.com (play)
