Maybe also add “in progress”? So items do not disappear suddenly from the page when work really starts on them?
On Tue 11 Aug 2020 at 17:15, Gus Heck <gus.h...@gmail.com> wrote: > 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 < > ichattopadhy...@gmail.com> 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 <jan....@cominvent.com> >> 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 <noble.p...@gmail.com>: >>> >>> >>> > >>> >>> >>> > 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 <jan....@cominvent.com> >>> 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 <dawid.we...@gmail.com>: >>> >>> >>> >> >>> >>> >>> >> >>> >>> >>> >>> 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: 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 >>> >>> >>> >>> >>> >>> >> >> > > -- > http://www.needhamsoftware.com (work) > http://www.the111shift.com (play) > > >
