You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@lucene.apache.org by Gus Heck <gu...@gmail.com> on 2020/07/02 16:58:17 UTC
RoadMap?
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)
Re: RoadMap?
Posted by Atri Sharma <at...@apache.org>.
+1
On Thu, Jul 2, 2020 at 10:28 PM Gus Heck <gu...@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)
--
Regards,
Atri
Apache Concerted
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@lucene.apache.org
For additional commands, e-mail: dev-help@lucene.apache.org
Re: RoadMap?
Posted by Marcus Eagan <ma...@gmail.com>.
+1 (non-binding)
On Tue, Aug 11, 2020 at 09:52 Gus Heck <gu...@gmail.com> wrote:
> I was thinking that level of detail is in the Jira... I don't see any
> reason for things to disappear (in fact rejected should go in a rejected
> list for future reference.)
>
> On Tue, Aug 11, 2020 at 12:04 PM Ilan Ginzburg <il...@gmail.com> wrote:
>
>> 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 <gu...@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 <
>>> ichattopadhyaya@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 <ja...@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 <no...@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 <ja...@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 <da...@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-unsubscribe@lucene.apache.org
>>>>>
>>>>>
>>>>> > For additional commands, e-mail: dev-help@lucene.apache.org
>>>>>
>>>>>
>>>>> >
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>> ---------------------------------------------------------------------
>>>>>
>>>>>
>>>>> To unsubscribe, e-mail: dev-unsubscribe@lucene.apache.org
>>>>>
>>>>>
>>>>> For additional commands, e-mail: dev-help@lucene.apache.org
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>
>>>>
>>>
>>> --
>>> http://www.needhamsoftware.com (work)
>>> http://www.the111shift.com (play)
>>>
>>>
>>>
>
> --
> http://www.needhamsoftware.com (work)
> http://www.the111shift.com (play)
>
--
Marcus Eagan
Re: RoadMap?
Posted by Erick Erickson <er...@gmail.com>.
IMO, it’s super-awkward to preserve something for 9.0 then remove it for 9.1. I understand the tendency to say “deprecating it in 8.7 then removing it in the next release is too fast”, but that strikes me as even worse than taking it out of 9.0.
> On Aug 27, 2020, at 6:35 PM, David Smiley <ds...@apache.org> wrote:
>
> It has been proposed on the list to NOT rip out all deprecations in 9.0, but allow users to upgrade to 9.0 with e.g. SolrCell still available, and then have yet some time to change their processes to adapt to the new way of doing stuff. I like that proposal. Sure, 9.0 will remove lots of deprecated code, but I think it is a mistake to do all of the proposed removals at once. We can spread removals out in 9.x releases, after users have had a few releases with a choice between old and new and the new alternative is solid.
>
> I find it highly depressing that we can't, *in a major release*, manage to get rid of our deprecations -- particularly for code that has a new home and is packaged in a form that is trivial to install (thanks to our new awesome package manager). I'm sympathetic to waiting to delete until *after* there is an actual package ready at that time (rather than just the promise of one).
>
> Also, users generally are cautious on performing a major version upgrade. There's time.
>
> ~ David Smiley
> Apache Lucene/Solr Search Developer
> http://www.linkedin.com/in/davidwsmiley
>
>
> On Wed, Aug 12, 2020 at 4:06 AM Jan Høydahl <ja...@cominvent.com> wrote:
> I edited the page to introduce the (super important) Solr TLP split into the roadmap.
> Also added a rough timeframe and a «major theme» for each release above the issue table.
> I added 8.8 and 9.1 as I think it is important to track what gets done just before 9.0 and what can be deferred to after 9.0.
>
> It has been proposed on the list to NOT rip out all deprecations in 9.0, but allow users to upgrade to 9.0 with e.g. SolrCell still available, and then have yet some time to change their processes to adapt to the new way of doing stuff. I like that proposal. Sure, 9.0 will remove lots of deprecated code, but I think it is a mistake to do all of the proposed removals at once. We can spread removals out in 9.x releases, after users have had a few releases with a choice between old and new and the new alternative is solid.
>
> Thanks Gus for taking ownership and suggesting a process! Feel free to rework what I edited into a structure you see more fit.
>
> Jan
>
>> 11. aug. 2020 kl. 18:51 skrev Gus Heck <gu...@gmail.com>:
>>
>> I was thinking that level of detail is in the Jira... I don't see any reason for things to disappear (in fact rejected should go in a rejected list for future reference.)
>>
>> On Tue, Aug 11, 2020 at 12:04 PM Ilan Ginzburg <il...@gmail.com> wrote:
>> 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 <gu...@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 <ic...@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 <ja...@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 <no...@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 <ja...@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 <da...@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-unsubscribe@lucene.apache.org
>>
>>
>> > For additional commands, e-mail: dev-help@lucene.apache.org
>>
>>
>> >
>>
>>
>>
>>
>>
>>
>>
>>
>> ---------------------------------------------------------------------
>>
>>
>> To unsubscribe, e-mail: dev-unsubscribe@lucene.apache.org
>>
>>
>> For additional commands, e-mail: dev-help@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-unsubscribe@lucene.apache.org
For additional commands, e-mail: dev-help@lucene.apache.org
Re: RoadMap?
Posted by Gus Heck <gu...@gmail.com>.
As amusing as the pattern has been (6.6, 7.7, 8.8?) we don't actually have
to release 9 point releases (9.9) before 10.0 :). I'd advocate that some
things we don't feel we can remove in 9.0 hang on for a few point releases
and when we're ready to ditch them we declare 10.0. if that's after 9.2 or
9.3 that's fine...
I agree that to drop support for something major we should hold a [VOTE].
Additionally I suggest that the vote thread should include specification of
the timeline (in terms of releases) for deprecate/removal
-Gus
On Fri, Aug 28, 2020 at 10:50 AM Jan Høydahl <ja...@cominvent.com> wrote:
> Noble, we all agree on those principles and that direction.
>
> But 9.0 is not the last chance to remove things. I think we must decide on
> a feature-by feature basis:
> - Whether the feature should remain a ASF maintained feature or not
> - If yes, we should make it into a 1st party package distributed in our
> own repo
> - If no, we must decide what is the right time to remove it from the
> distro.
> - If an alternative package already exists, it can be removed in next
> major
> - If not, we must decide how long time our users need to prepare an
> alternative (3rd party pkg or home-grown)
>
> When propose to stop maintaining a feature as part of the project, a
> [VOTE] thread is an excellent way to make such a decision.
>
> Jan
>
> > 28. aug. 2020 kl. 14:35 skrev Noble Paul <no...@gmail.com>:
> >
> > We do not have to provide all features. Whatever feature we provide,
> > it should be reasonably bug free, performant and stable.
> >
> > There is no point in carrying around a lot of baggage if we are barely
> > able to carry it. There are a lot of "dark areas" in Solr which nobody
> > pays attention to. Those features should be removed altogether. If
> > there are committers who wish to actively support it , we can maintain
> > them in packages. If, not we should euthanize them gracefully
> >
> > On Fri, Aug 28, 2020 at 5:43 PM Ishan Chattopadhyaya
> > <ic...@gmail.com> wrote:
> >>
> >>> The consensus from yesterday seems to be that stuff with a released
> replacement can/should be removed in 9.0, but for CDCR and SolrCell, where
> the proejct still wants to provide a better alternative, they can remain
> deprecated 9.x.
> >>
> >> I disagree that "project still wants to provide a better alternative",
> at least for CDCR. There is no movement in that direction. Part of the
> reason people take supporting these features seriously is the threat or
> deprecation/removal (e.g. HDFS, Velocity, DIH, Autoscaling etc.). The
> moment we deprecate/remove SolrCell, we will see the better alternatives
> emerge. And both of them must be removed, even if better alternatives do
> not emerge. They both must be removed in 9.0. Let us not carry the burden
> into another major release.
> >>
> >> On Fri, Aug 28, 2020 at 12:49 PM Jan Høydahl <ja...@cominvent.com>
> wrote:
> >>>
> >>> Hi,
> >>>
> >>> I phrased that sentence in the roadmap Wiki, but I think the wording
> is more conservative than need-be. The intent was really to avoid a
> situation where 9.0 goes out the door «tomorrow» without a replacement for
> a popular feature that the community really wants. I attempted a re-phrase
> of that sentence after the meeting yesterday, but did not immediately find
> a better wording.
> >>>
> >>> Personally I think a deprecation in 8.6 can be removed in 9.0
> (there’ll be several months and 2’ish releases in between) if it has a well
> known, released replacement/package. And let’s link to those packages in
> ref-guide and link to the ref-guide from the release-note. I.e. ref-guide
> currently ways DIH is to be removed, perhaps that page could instead
> explain how to obtain the package, and at the same time encourage users to
> contribute to maintaining it?
> >>>
> >>> The consensus from yesterday seems to be that stuff with a released
> replacement can/should be removed in 9.0, but for CDCR and SolrCell, where
> the proejct still wants to provide a better alternative, they can remain
> deprecated 9.x. In particular for SolrCell we can’t imagine how many users
> it has out there. Even after inventing its successor based on TikaServer,
> integrated in SolrJ or whatever, I would advocate for the good-old
> ExtractingRequestHandler to be available as a package for a few releases to
> come.
> >>>
> >>> Wrt whether something could be removed in 9.1 as long as it was
> deprecated in 8.x, I would initially say YES, at least legally/technically.
> We’re not breaking any back-compat promise as long as it has been
> prominently flagged as deprecated for so long. However, I can see how
> people not reading documentation downloads 9.0.0, starts using a deprecated
> feature and then complains when it is gone in 9.3 :)
> >>>
> >>> We also have an option to release Solr 10.0 (Solr X) sooner rather
> than later (even on Lucene 9.x). Looks like we have tons of major goodies
> lined up - it won’t all need to land in 9.0. Guess that’s what the Roadmap
> page is there for. So as David says, let’s start placing the removal JIRAs
> into the roadmap page and see if we’re still on the same page?
> >>>
> >>> Jan
> >>>
> >>> 28. aug. 2020 kl. 07:43 skrev David Smiley <ds...@apache.org>:
> >>>
> >>>
> >>> On Thu, Aug 27, 2020 at 7:03 PM Ishan Chattopadhyaya <
> ichattopadhyaya@gmail.com> wrote:
> >>>>
> >>>>> I find it highly depressing that we can't, *in a major release*,
> manage to get rid of our deprecations -- particularly for code that has a
> new home and is packaged in a form that is trivial to install (thanks to
> our new awesome package manager).
> >>>>
> >>>> I'm not sure why you think "we can't". I can't even remember a single
> committer standing in the way of removing those *that already have a
> package*.
> >>>
> >>>
> >>> Okay, maybe I read the intent wrong. I can see the example given was
> about Solr Cell, which apparently has no new home, so I'm +0 with keeping
> it for 9.0.
> >>>
> >>> Also, on the roadmap cwiki:
> >>>
> >>>> We should not remove all features/APIs deprecated in 8.x yet, to give
> users a path to upgrade to 9.x without all the extra noise. Deprecated
> features can be removed in a later 9.x release, when the new alternative is
> solid and well known.
> >>>
> >>>
> >>> Again, maybe I'm misreading but I'd like to us to manage to remove a
> lot of deprecated stuff as the norm. There will be exceptions to the norm
> -- Solr Cell, CDCR. To make this point clear, I wish to add to the
> roadmap, Solr 9.0 table, first row, saying basically "Remove lots of
> deprecated stuff" with some JIRAs linked like
> https://issues.apache.org/jira/browse/SOLR-13138
> >>>
> >>> ~ David
> >>>
> >>>
> >
> >
> > --
> > -----------------------------------------------------
> > Noble Paul
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: dev-unsubscribe@lucene.apache.org
> > For additional commands, e-mail: dev-help@lucene.apache.org
> >
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@lucene.apache.org
> For additional commands, e-mail: dev-help@lucene.apache.org
>
>
--
http://www.needhamsoftware.com (work)
http://www.the111shift.com (play)
Re: RoadMap?
Posted by Jan Høydahl <ja...@cominvent.com>.
Noble, we all agree on those principles and that direction.
But 9.0 is not the last chance to remove things. I think we must decide on a feature-by feature basis:
- Whether the feature should remain a ASF maintained feature or not
- If yes, we should make it into a 1st party package distributed in our own repo
- If no, we must decide what is the right time to remove it from the distro.
- If an alternative package already exists, it can be removed in next major
- If not, we must decide how long time our users need to prepare an alternative (3rd party pkg or home-grown)
When propose to stop maintaining a feature as part of the project, a [VOTE] thread is an excellent way to make such a decision.
Jan
> 28. aug. 2020 kl. 14:35 skrev Noble Paul <no...@gmail.com>:
>
> We do not have to provide all features. Whatever feature we provide,
> it should be reasonably bug free, performant and stable.
>
> There is no point in carrying around a lot of baggage if we are barely
> able to carry it. There are a lot of "dark areas" in Solr which nobody
> pays attention to. Those features should be removed altogether. If
> there are committers who wish to actively support it , we can maintain
> them in packages. If, not we should euthanize them gracefully
>
> On Fri, Aug 28, 2020 at 5:43 PM Ishan Chattopadhyaya
> <ic...@gmail.com> wrote:
>>
>>> The consensus from yesterday seems to be that stuff with a released replacement can/should be removed in 9.0, but for CDCR and SolrCell, where the proejct still wants to provide a better alternative, they can remain deprecated 9.x.
>>
>> I disagree that "project still wants to provide a better alternative", at least for CDCR. There is no movement in that direction. Part of the reason people take supporting these features seriously is the threat or deprecation/removal (e.g. HDFS, Velocity, DIH, Autoscaling etc.). The moment we deprecate/remove SolrCell, we will see the better alternatives emerge. And both of them must be removed, even if better alternatives do not emerge. They both must be removed in 9.0. Let us not carry the burden into another major release.
>>
>> On Fri, Aug 28, 2020 at 12:49 PM Jan Høydahl <ja...@cominvent.com> wrote:
>>>
>>> Hi,
>>>
>>> I phrased that sentence in the roadmap Wiki, but I think the wording is more conservative than need-be. The intent was really to avoid a situation where 9.0 goes out the door «tomorrow» without a replacement for a popular feature that the community really wants. I attempted a re-phrase of that sentence after the meeting yesterday, but did not immediately find a better wording.
>>>
>>> Personally I think a deprecation in 8.6 can be removed in 9.0 (there’ll be several months and 2’ish releases in between) if it has a well known, released replacement/package. And let’s link to those packages in ref-guide and link to the ref-guide from the release-note. I.e. ref-guide currently ways DIH is to be removed, perhaps that page could instead explain how to obtain the package, and at the same time encourage users to contribute to maintaining it?
>>>
>>> The consensus from yesterday seems to be that stuff with a released replacement can/should be removed in 9.0, but for CDCR and SolrCell, where the proejct still wants to provide a better alternative, they can remain deprecated 9.x. In particular for SolrCell we can’t imagine how many users it has out there. Even after inventing its successor based on TikaServer, integrated in SolrJ or whatever, I would advocate for the good-old ExtractingRequestHandler to be available as a package for a few releases to come.
>>>
>>> Wrt whether something could be removed in 9.1 as long as it was deprecated in 8.x, I would initially say YES, at least legally/technically. We’re not breaking any back-compat promise as long as it has been prominently flagged as deprecated for so long. However, I can see how people not reading documentation downloads 9.0.0, starts using a deprecated feature and then complains when it is gone in 9.3 :)
>>>
>>> We also have an option to release Solr 10.0 (Solr X) sooner rather than later (even on Lucene 9.x). Looks like we have tons of major goodies lined up - it won’t all need to land in 9.0. Guess that’s what the Roadmap page is there for. So as David says, let’s start placing the removal JIRAs into the roadmap page and see if we’re still on the same page?
>>>
>>> Jan
>>>
>>> 28. aug. 2020 kl. 07:43 skrev David Smiley <ds...@apache.org>:
>>>
>>>
>>> On Thu, Aug 27, 2020 at 7:03 PM Ishan Chattopadhyaya <ic...@gmail.com> wrote:
>>>>
>>>>> I find it highly depressing that we can't, *in a major release*, manage to get rid of our deprecations -- particularly for code that has a new home and is packaged in a form that is trivial to install (thanks to our new awesome package manager).
>>>>
>>>> I'm not sure why you think "we can't". I can't even remember a single committer standing in the way of removing those *that already have a package*.
>>>
>>>
>>> Okay, maybe I read the intent wrong. I can see the example given was about Solr Cell, which apparently has no new home, so I'm +0 with keeping it for 9.0.
>>>
>>> Also, on the roadmap cwiki:
>>>
>>>> We should not remove all features/APIs deprecated in 8.x yet, to give users a path to upgrade to 9.x without all the extra noise. Deprecated features can be removed in a later 9.x release, when the new alternative is solid and well known.
>>>
>>>
>>> Again, maybe I'm misreading but I'd like to us to manage to remove a lot of deprecated stuff as the norm. There will be exceptions to the norm -- Solr Cell, CDCR. To make this point clear, I wish to add to the roadmap, Solr 9.0 table, first row, saying basically "Remove lots of deprecated stuff" with some JIRAs linked like https://issues.apache.org/jira/browse/SOLR-13138
>>>
>>> ~ David
>>>
>>>
>
>
> --
> -----------------------------------------------------
> Noble Paul
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@lucene.apache.org
> For additional commands, e-mail: dev-help@lucene.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@lucene.apache.org
For additional commands, e-mail: dev-help@lucene.apache.org
Re: RoadMap?
Posted by Noble Paul <no...@gmail.com>.
We do not have to provide all features. Whatever feature we provide,
it should be reasonably bug free, performant and stable.
There is no point in carrying around a lot of baggage if we are barely
able to carry it. There are a lot of "dark areas" in Solr which nobody
pays attention to. Those features should be removed altogether. If
there are committers who wish to actively support it , we can maintain
them in packages. If, not we should euthanize them gracefully
On Fri, Aug 28, 2020 at 5:43 PM Ishan Chattopadhyaya
<ic...@gmail.com> wrote:
>
> > The consensus from yesterday seems to be that stuff with a released replacement can/should be removed in 9.0, but for CDCR and SolrCell, where the proejct still wants to provide a better alternative, they can remain deprecated 9.x.
>
> I disagree that "project still wants to provide a better alternative", at least for CDCR. There is no movement in that direction. Part of the reason people take supporting these features seriously is the threat or deprecation/removal (e.g. HDFS, Velocity, DIH, Autoscaling etc.). The moment we deprecate/remove SolrCell, we will see the better alternatives emerge. And both of them must be removed, even if better alternatives do not emerge. They both must be removed in 9.0. Let us not carry the burden into another major release.
>
> On Fri, Aug 28, 2020 at 12:49 PM Jan Høydahl <ja...@cominvent.com> wrote:
>>
>> Hi,
>>
>> I phrased that sentence in the roadmap Wiki, but I think the wording is more conservative than need-be. The intent was really to avoid a situation where 9.0 goes out the door «tomorrow» without a replacement for a popular feature that the community really wants. I attempted a re-phrase of that sentence after the meeting yesterday, but did not immediately find a better wording.
>>
>> Personally I think a deprecation in 8.6 can be removed in 9.0 (there’ll be several months and 2’ish releases in between) if it has a well known, released replacement/package. And let’s link to those packages in ref-guide and link to the ref-guide from the release-note. I.e. ref-guide currently ways DIH is to be removed, perhaps that page could instead explain how to obtain the package, and at the same time encourage users to contribute to maintaining it?
>>
>> The consensus from yesterday seems to be that stuff with a released replacement can/should be removed in 9.0, but for CDCR and SolrCell, where the proejct still wants to provide a better alternative, they can remain deprecated 9.x. In particular for SolrCell we can’t imagine how many users it has out there. Even after inventing its successor based on TikaServer, integrated in SolrJ or whatever, I would advocate for the good-old ExtractingRequestHandler to be available as a package for a few releases to come.
>>
>> Wrt whether something could be removed in 9.1 as long as it was deprecated in 8.x, I would initially say YES, at least legally/technically. We’re not breaking any back-compat promise as long as it has been prominently flagged as deprecated for so long. However, I can see how people not reading documentation downloads 9.0.0, starts using a deprecated feature and then complains when it is gone in 9.3 :)
>>
>> We also have an option to release Solr 10.0 (Solr X) sooner rather than later (even on Lucene 9.x). Looks like we have tons of major goodies lined up - it won’t all need to land in 9.0. Guess that’s what the Roadmap page is there for. So as David says, let’s start placing the removal JIRAs into the roadmap page and see if we’re still on the same page?
>>
>> Jan
>>
>> 28. aug. 2020 kl. 07:43 skrev David Smiley <ds...@apache.org>:
>>
>>
>> On Thu, Aug 27, 2020 at 7:03 PM Ishan Chattopadhyaya <ic...@gmail.com> wrote:
>>>
>>> > I find it highly depressing that we can't, *in a major release*, manage to get rid of our deprecations -- particularly for code that has a new home and is packaged in a form that is trivial to install (thanks to our new awesome package manager).
>>>
>>> I'm not sure why you think "we can't". I can't even remember a single committer standing in the way of removing those *that already have a package*.
>>
>>
>> Okay, maybe I read the intent wrong. I can see the example given was about Solr Cell, which apparently has no new home, so I'm +0 with keeping it for 9.0.
>>
>> Also, on the roadmap cwiki:
>>
>>> We should not remove all features/APIs deprecated in 8.x yet, to give users a path to upgrade to 9.x without all the extra noise. Deprecated features can be removed in a later 9.x release, when the new alternative is solid and well known.
>>
>>
>> Again, maybe I'm misreading but I'd like to us to manage to remove a lot of deprecated stuff as the norm. There will be exceptions to the norm -- Solr Cell, CDCR. To make this point clear, I wish to add to the roadmap, Solr 9.0 table, first row, saying basically "Remove lots of deprecated stuff" with some JIRAs linked like https://issues.apache.org/jira/browse/SOLR-13138
>>
>> ~ David
>>
>>
--
-----------------------------------------------------
Noble Paul
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@lucene.apache.org
For additional commands, e-mail: dev-help@lucene.apache.org
Re: RoadMap?
Posted by Ishan Chattopadhyaya <ic...@gmail.com>.
> The consensus from yesterday seems to be that stuff with a released
replacement can/should be removed in 9.0, but for CDCR and SolrCell, where
the proejct still wants to provide a better alternative, they can remain
deprecated 9.x.
I disagree that "project still wants to provide a better alternative", at
least for CDCR. There is no movement in that direction. Part of the reason
people take supporting these features seriously is the threat or
deprecation/removal (e.g. HDFS, Velocity, DIH, Autoscaling etc.). The
moment we deprecate/remove SolrCell, we will see the better alternatives
emerge. And both of them must be removed, even if better alternatives do
not emerge. They both must be removed in 9.0. Let us not carry the burden
into another major release.
On Fri, Aug 28, 2020 at 12:49 PM Jan Høydahl <ja...@cominvent.com> wrote:
> Hi,
>
> I phrased that sentence in the roadmap Wiki, but I think the wording is
> more conservative than need-be. The intent was really to avoid a situation
> where 9.0 goes out the door «tomorrow» without a replacement for a popular
> feature that the community really wants. I attempted a re-phrase of that
> sentence after the meeting yesterday, but did not immediately find a better
> wording.
>
> Personally I think a deprecation in 8.6 can be removed in 9.0 (there’ll be
> several months and 2’ish releases in between) if it has a well known,
> released replacement/package. And let’s link to those packages in ref-guide
> and link to the ref-guide from the release-note. I.e. ref-guide
> <https://nightlies.apache.org/Lucene/Solr-reference-guide-master/uploading-structured-data-store-data-with-the-data-import-handler.html> currently
> ways DIH is to be removed, perhaps that page could instead explain how to
> obtain the package, and at the same time encourage users to contribute to
> maintaining it?
>
> The consensus from yesterday seems to be that stuff with a released
> replacement can/should be removed in 9.0, but for CDCR and SolrCell, where
> the proejct still wants to provide a better alternative, they can remain
> deprecated 9.x. In particular for SolrCell we can’t imagine how many users
> it has out there. Even after inventing its successor based on TikaServer,
> integrated in SolrJ or whatever, I would advocate for the good-old
> ExtractingRequestHandler to be available as a package for a few releases to
> come.
>
> Wrt whether something could be removed in 9.1 as long as it was deprecated
> in 8.x, I would initially say YES, at least legally/technically. We’re not
> breaking any back-compat promise as long as it has been prominently flagged
> as deprecated for so long. However, I can see how people not reading
> documentation downloads 9.0.0, starts using a deprecated feature and then
> complains when it is gone in 9.3 :)
>
> We also have an option to release Solr 10.0 (Solr X) sooner rather than
> later (even on Lucene 9.x). Looks like we have tons of major goodies lined
> up - it won’t all need to land in 9.0. Guess that’s what the Roadmap page
> is there for. So as David says, let’s start placing the removal JIRAs into
> the roadmap page and see if we’re still on the same page?
>
> Jan
>
> 28. aug. 2020 kl. 07:43 skrev David Smiley <ds...@apache.org>:
>
>
> On Thu, Aug 27, 2020 at 7:03 PM Ishan Chattopadhyaya <
> ichattopadhyaya@gmail.com> wrote:
>
>> > I find it highly depressing that we can't, *in a major release*, manage
>> to get rid of our deprecations -- particularly for code that has a new home
>> and is packaged in a form that is trivial to install (thanks to our new
>> awesome package manager).
>>
>> I'm not sure why you think "we can't". I can't even remember a single
>> committer standing in the way of removing those *that already have a
>> package*.
>>
>
> Okay, maybe I read the intent wrong. I can see the example given was
> about Solr Cell, which apparently has no new home, so I'm +0 with keeping
> it for 9.0.
>
> Also, on the roadmap cwiki:
>
> We should *not* remove all features/APIs deprecated in 8.x yet, to give
>> users a path to upgrade to 9.x without all the extra noise. Deprecated
>> features can be removed in a later 9.x release, when the new alternative is
>> solid and well known.
>
>
> Again, maybe I'm misreading but I'd like to us to manage to remove a lot
> of deprecated stuff *as the norm*. There will be exceptions to the norm
> -- Solr Cell, CDCR. To make this point clear, I wish to add to the
> roadmap, Solr 9.0 table, first row, saying basically "Remove lots of
> deprecated stuff" with some JIRAs linked like
> https://issues.apache.org/jira/browse/SOLR-13138
>
> ~ David
>
>
>
Re: RoadMap?
Posted by Jan Høydahl <ja...@cominvent.com>.
Hi,
I phrased that sentence in the roadmap Wiki, but I think the wording is more conservative than need-be. The intent was really to avoid a situation where 9.0 goes out the door «tomorrow» without a replacement for a popular feature that the community really wants. I attempted a re-phrase of that sentence after the meeting yesterday, but did not immediately find a better wording.
Personally I think a deprecation in 8.6 can be removed in 9.0 (there’ll be several months and 2’ish releases in between) if it has a well known, released replacement/package. And let’s link to those packages in ref-guide and link to the ref-guide from the release-note. I.e. ref-guide <https://nightlies.apache.org/Lucene/Solr-reference-guide-master/uploading-structured-data-store-data-with-the-data-import-handler.html> currently ways DIH is to be removed, perhaps that page could instead explain how to obtain the package, and at the same time encourage users to contribute to maintaining it?
The consensus from yesterday seems to be that stuff with a released replacement can/should be removed in 9.0, but for CDCR and SolrCell, where the proejct still wants to provide a better alternative, they can remain deprecated 9.x. In particular for SolrCell we can’t imagine how many users it has out there. Even after inventing its successor based on TikaServer, integrated in SolrJ or whatever, I would advocate for the good-old ExtractingRequestHandler to be available as a package for a few releases to come.
Wrt whether something could be removed in 9.1 as long as it was deprecated in 8.x, I would initially say YES, at least legally/technically. We’re not breaking any back-compat promise as long as it has been prominently flagged as deprecated for so long. However, I can see how people not reading documentation downloads 9.0.0, starts using a deprecated feature and then complains when it is gone in 9.3 :)
We also have an option to release Solr 10.0 (Solr X) sooner rather than later (even on Lucene 9.x). Looks like we have tons of major goodies lined up - it won’t all need to land in 9.0. Guess that’s what the Roadmap page is there for. So as David says, let’s start placing the removal JIRAs into the roadmap page and see if we’re still on the same page?
Jan
> 28. aug. 2020 kl. 07:43 skrev David Smiley <ds...@apache.org>:
>
>
> On Thu, Aug 27, 2020 at 7:03 PM Ishan Chattopadhyaya <ichattopadhyaya@gmail.com <ma...@gmail.com>> wrote:
> > I find it highly depressing that we can't, *in a major release*, manage to get rid of our deprecations -- particularly for code that has a new home and is packaged in a form that is trivial to install (thanks to our new awesome package manager).
>
> I'm not sure why you think "we can't". I can't even remember a single committer standing in the way of removing those *that already have a package*.
>
> Okay, maybe I read the intent wrong. I can see the example given was about Solr Cell, which apparently has no new home, so I'm +0 with keeping it for 9.0.
>
> Also, on the roadmap cwiki:
>
> We should not remove all features/APIs deprecated in 8.x yet, to give users a path to upgrade to 9.x without all the extra noise. Deprecated features can be removed in a later 9.x release, when the new alternative is solid and well known.
>
> Again, maybe I'm misreading but I'd like to us to manage to remove a lot of deprecated stuff as the norm. There will be exceptions to the norm -- Solr Cell, CDCR. To make this point clear, I wish to add to the roadmap, Solr 9.0 table, first row, saying basically "Remove lots of deprecated stuff" with some JIRAs linked like https://issues.apache.org/jira/browse/SOLR-13138 <https://issues.apache.org/jira/browse/SOLR-13138>
>
> ~ David
Re: RoadMap?
Posted by David Smiley <ds...@apache.org>.
On Thu, Aug 27, 2020 at 7:03 PM Ishan Chattopadhyaya <
ichattopadhyaya@gmail.com> wrote:
> > I find it highly depressing that we can't, *in a major release*, manage
> to get rid of our deprecations -- particularly for code that has a new home
> and is packaged in a form that is trivial to install (thanks to our new
> awesome package manager).
>
> I'm not sure why you think "we can't". I can't even remember a single
> committer standing in the way of removing those *that already have a
> package*.
>
Okay, maybe I read the intent wrong. I can see the example given was about
Solr Cell, which apparently has no new home, so I'm +0 with keeping it for
9.0.
Also, on the roadmap cwiki:
We should *not* remove all features/APIs deprecated in 8.x yet, to give
> users a path to upgrade to 9.x without all the extra noise. Deprecated
> features can be removed in a later 9.x release, when the new alternative is
> solid and well known.
Again, maybe I'm misreading but I'd like to us to manage to remove a lot of
deprecated stuff *as the norm*. There will be exceptions to the norm --
Solr Cell, CDCR. To make this point clear, I wish to add to the roadmap,
Solr 9.0 table, first row, saying basically "Remove lots of deprecated
stuff" with some JIRAs linked like
https://issues.apache.org/jira/browse/SOLR-13138
~ David
Re: RoadMap?
Posted by Alexandre Rafalovitch <ar...@gmail.com>.
Ok, sounds like UIMA repeat to me.
+1 to take it out and point at one of those other solutions in CHANGES
or whatever.
Regards,
Alex.
On Thu, 27 Aug 2020 at 20:45, Erick Erickson <er...@gmail.com> wrote:
>
> CDCR does work, kind of. But it requires extensive care and feeding and, as Ishan says, it’s _very_ easy to shoot yourself in the foot. Or run out of disk space. Or get to a state where you have to replicate the index. And “bi-directional” means you can go from A -> B _or_ B -> A, but you can’t index to both A and B at once. Anyone who’s using it invariably rolls their own monitoring to make sure it’s still running. You want “fire and forget” functionality, but that’s not where CDCR is at.
>
> The consequence of not having the monitoring in place is that the tlogs fill up, and then your index can become corrupt. Yes, it’s fixable, but there’s always problem N+1...
>
> I think CDCR could be made acceptable _if_ someone was willing to own it and devote a lot of time to maintenance. But nobody is stepping up to do it, certainly not me. And it’s a side issue, Solr is a search engine. There are solutions out there that are built from the start to deal with keeping separate DCs in sync. Let’s use those rather than a “kinda works” solution.
>
> One of the problems with Solr is that it’s become a hodgepodge of peripheral stuff that somebody found useful at some point. And in a number of instances, capabilities were added to Solr when no other tools were available. But the state of the art have progressed, it’s time to jettison older stuff...
>
> The advantage of CDCR is that it is all contained in Solr, no outside packages required. The disadvantage is that has very few people willing to work on it.
>
> So I’m for taking it out of Solr. My prediction is that if it’s made a package, it’ll languish and at some point become unusable with the then-current version of Solr. And nobody who complains will be willing to devote the time and effort to making it work with Solr X.Y.
>
> FWIW...
>
>
> > On Aug 27, 2020, at 7:50 PM, Ishan Chattopadhyaya <ic...@gmail.com> wrote:
> >
> > It does start. It is broken because it is fraught with dangers of users shooting themselves in their feet. Some context here: https://issues.apache.org/jira/browse/SOLR-14616?focusedCommentId=17153129&page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-17153129
> >
> > On Fri, Aug 28, 2020 at 4:52 AM Alexandre Rafalovitch <ar...@gmail.com> wrote:
> > If CDCR is actively broken (does not start?), then isn't it
> > effectively deprecated from the last version that did not work? And if
> > it is not going to be maintained, then isn't the 'latest' version is
> > whichever we still did not delete it in. Because a broken feature is
> > only worth keeping in, if we ever plan to fix it.
> >
> > We have been through the same with UIMA, if I recall. It was broken
> > for a bit and then when I pulled it, ONE person got all upset.
> > SOLR-11694
> >
> > Regards,
> > Alex
> > Ps. I don't know the degree of 'broken' of this specific feature. So,
> > I am mostly talking practical principles here.
> >
> > On Thu, 27 Aug 2020 at 19:03, Ishan Chattopadhyaya
> > <ic...@gmail.com> wrote:
> > >
> > > > I find it highly depressing that we can't, *in a major release*, manage to get rid of our deprecations -- particularly for code that has a new home and is packaged in a form that is trivial to install (thanks to our new awesome package manager).
> > >
> > > I'm not sure why you think "we can't". I can't even remember a single committer standing in the way of removing those *that already have a package*. However, there's a backlash against removing CDCR even though there is no one volunteering to support it (as a package) and it is clearly broken, which is what totally puzzles me. https://issues.apache.org/jira/browse/SOLR-14616
> > >
> > > On Fri, Aug 28, 2020 at 4:19 AM Alexandre Rafalovitch <ar...@gmail.com> wrote:
> > >>
> > >> Well, I have created SOLR-14783 (Remove DIH from 9.0) and am busily
> > >> learning magic gradle commands to make that happen without leaving
> > >> behind random crumbs. Once that lands, I will do Jira search on all
> > >> DIH still-open tasks after that and close them pointing to the said
> > >> Jira.
> > >>
> > >> So, I guess somebody better -1 the Jira if they really want that one
> > >> to stay until ... ? And then read very carefully through SIP-10 of
> > >> which, this is just a first step.
> > >>
> > >> In general, maybe we can manage to do so many new features and cleanup
> > >> in 9 that will make Solr TLP look like a great Big Bang moment...
> > >>
> > >> And it will probably take a little longer to achieve that, so the -
> > >> effective - deprecation schedule would still be ok.
> > >>
> > >> Regards,
> > >> Alex.
> > >>
> > >> On Thu, 27 Aug 2020 at 18:35, David Smiley <ds...@apache.org> wrote:
> > >> >>
> > >> >> It has been proposed on the list to NOT rip out all deprecations in 9.0, but allow users to upgrade to 9.0 with e.g. SolrCell still available, and then have yet some time to change their processes to adapt to the new way of doing stuff. I like that proposal. Sure, 9.0 will remove lots of deprecated code, but I think it is a mistake to do all of the proposed removals at once. We can spread removals out in 9.x releases, after users have had a few releases with a choice between old and new and the new alternative is solid.
> > >> >
> > >> >
> > >> > I find it highly depressing that we can't, *in a major release*, manage to get rid of our deprecations -- particularly for code that has a new home and is packaged in a form that is trivial to install (thanks to our new awesome package manager). I'm sympathetic to waiting to delete until *after* there is an actual package ready at that time (rather than just the promise of one).
> > >> >
> > >> > Also, users generally are cautious on performing a major version upgrade. There's time.
> > >> >
> > >> > ~ David Smiley
> > >> > Apache Lucene/Solr Search Developer
> > >> > http://www.linkedin.com/in/davidwsmiley
> > >> >
> > >> >
> > >> > On Wed, Aug 12, 2020 at 4:06 AM Jan Høydahl <ja...@cominvent.com> wrote:
> > >> >>
> > >> >> I edited the page to introduce the (super important) Solr TLP split into the roadmap.
> > >> >> Also added a rough timeframe and a «major theme» for each release above the issue table.
> > >> >> I added 8.8 and 9.1 as I think it is important to track what gets done just before 9.0 and what can be deferred to after 9.0.
> > >> >>
> > >> >> It has been proposed on the list to NOT rip out all deprecations in 9.0, but allow users to upgrade to 9.0 with e.g. SolrCell still available, and then have yet some time to change their processes to adapt to the new way of doing stuff. I like that proposal. Sure, 9.0 will remove lots of deprecated code, but I think it is a mistake to do all of the proposed removals at once. We can spread removals out in 9.x releases, after users have had a few releases with a choice between old and new and the new alternative is solid.
> > >> >>
> > >> >> Thanks Gus for taking ownership and suggesting a process! Feel free to rework what I edited into a structure you see more fit.
> > >> >>
> > >> >> Jan
> > >> >>
> > >> >> 11. aug. 2020 kl. 18:51 skrev Gus Heck <gu...@gmail.com>:
> > >> >>
> > >> >> I was thinking that level of detail is in the Jira... I don't see any reason for things to disappear (in fact rejected should go in a rejected list for future reference.)
> > >> >>
> > >> >> On Tue, Aug 11, 2020 at 12:04 PM Ilan Ginzburg <il...@gmail.com> wrote:
> > >> >>>
> > >> >>> 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 <gu...@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 <ic...@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 <ja...@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 <no...@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 <ja...@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 <da...@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-unsubscribe@lucene.apache.org
> > >> >>>>>>
> > >> >>>>>>
> > >> >>>>>> > For additional commands, e-mail: dev-help@lucene.apache.org
> > >> >>>>>>
> > >> >>>>>>
> > >> >>>>>> >
> > >> >>>>>>
> > >> >>>>>>
> > >> >>>>>>
> > >> >>>>>>
> > >> >>>>>>
> > >> >>>>>>
> > >> >>>>>>
> > >> >>>>>>
> > >> >>>>>> ---------------------------------------------------------------------
> > >> >>>>>>
> > >> >>>>>>
> > >> >>>>>> To unsubscribe, e-mail: dev-unsubscribe@lucene.apache.org
> > >> >>>>>>
> > >> >>>>>>
> > >> >>>>>> For additional commands, e-mail: dev-help@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-unsubscribe@lucene.apache.org
> > >> For additional commands, e-mail: dev-help@lucene.apache.org
> > >>
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: dev-unsubscribe@lucene.apache.org
> > For additional commands, e-mail: dev-help@lucene.apache.org
> >
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@lucene.apache.org
> For additional commands, e-mail: dev-help@lucene.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@lucene.apache.org
For additional commands, e-mail: dev-help@lucene.apache.org
Re: RoadMap?
Posted by Erick Erickson <er...@gmail.com>.
CDCR does work, kind of. But it requires extensive care and feeding and, as Ishan says, it’s _very_ easy to shoot yourself in the foot. Or run out of disk space. Or get to a state where you have to replicate the index. And “bi-directional” means you can go from A -> B _or_ B -> A, but you can’t index to both A and B at once. Anyone who’s using it invariably rolls their own monitoring to make sure it’s still running. You want “fire and forget” functionality, but that’s not where CDCR is at.
The consequence of not having the monitoring in place is that the tlogs fill up, and then your index can become corrupt. Yes, it’s fixable, but there’s always problem N+1...
I think CDCR could be made acceptable _if_ someone was willing to own it and devote a lot of time to maintenance. But nobody is stepping up to do it, certainly not me. And it’s a side issue, Solr is a search engine. There are solutions out there that are built from the start to deal with keeping separate DCs in sync. Let’s use those rather than a “kinda works” solution.
One of the problems with Solr is that it’s become a hodgepodge of peripheral stuff that somebody found useful at some point. And in a number of instances, capabilities were added to Solr when no other tools were available. But the state of the art have progressed, it’s time to jettison older stuff...
The advantage of CDCR is that it is all contained in Solr, no outside packages required. The disadvantage is that has very few people willing to work on it.
So I’m for taking it out of Solr. My prediction is that if it’s made a package, it’ll languish and at some point become unusable with the then-current version of Solr. And nobody who complains will be willing to devote the time and effort to making it work with Solr X.Y.
FWIW...
> On Aug 27, 2020, at 7:50 PM, Ishan Chattopadhyaya <ic...@gmail.com> wrote:
>
> It does start. It is broken because it is fraught with dangers of users shooting themselves in their feet. Some context here: https://issues.apache.org/jira/browse/SOLR-14616?focusedCommentId=17153129&page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-17153129
>
> On Fri, Aug 28, 2020 at 4:52 AM Alexandre Rafalovitch <ar...@gmail.com> wrote:
> If CDCR is actively broken (does not start?), then isn't it
> effectively deprecated from the last version that did not work? And if
> it is not going to be maintained, then isn't the 'latest' version is
> whichever we still did not delete it in. Because a broken feature is
> only worth keeping in, if we ever plan to fix it.
>
> We have been through the same with UIMA, if I recall. It was broken
> for a bit and then when I pulled it, ONE person got all upset.
> SOLR-11694
>
> Regards,
> Alex
> Ps. I don't know the degree of 'broken' of this specific feature. So,
> I am mostly talking practical principles here.
>
> On Thu, 27 Aug 2020 at 19:03, Ishan Chattopadhyaya
> <ic...@gmail.com> wrote:
> >
> > > I find it highly depressing that we can't, *in a major release*, manage to get rid of our deprecations -- particularly for code that has a new home and is packaged in a form that is trivial to install (thanks to our new awesome package manager).
> >
> > I'm not sure why you think "we can't". I can't even remember a single committer standing in the way of removing those *that already have a package*. However, there's a backlash against removing CDCR even though there is no one volunteering to support it (as a package) and it is clearly broken, which is what totally puzzles me. https://issues.apache.org/jira/browse/SOLR-14616
> >
> > On Fri, Aug 28, 2020 at 4:19 AM Alexandre Rafalovitch <ar...@gmail.com> wrote:
> >>
> >> Well, I have created SOLR-14783 (Remove DIH from 9.0) and am busily
> >> learning magic gradle commands to make that happen without leaving
> >> behind random crumbs. Once that lands, I will do Jira search on all
> >> DIH still-open tasks after that and close them pointing to the said
> >> Jira.
> >>
> >> So, I guess somebody better -1 the Jira if they really want that one
> >> to stay until ... ? And then read very carefully through SIP-10 of
> >> which, this is just a first step.
> >>
> >> In general, maybe we can manage to do so many new features and cleanup
> >> in 9 that will make Solr TLP look like a great Big Bang moment...
> >>
> >> And it will probably take a little longer to achieve that, so the -
> >> effective - deprecation schedule would still be ok.
> >>
> >> Regards,
> >> Alex.
> >>
> >> On Thu, 27 Aug 2020 at 18:35, David Smiley <ds...@apache.org> wrote:
> >> >>
> >> >> It has been proposed on the list to NOT rip out all deprecations in 9.0, but allow users to upgrade to 9.0 with e.g. SolrCell still available, and then have yet some time to change their processes to adapt to the new way of doing stuff. I like that proposal. Sure, 9.0 will remove lots of deprecated code, but I think it is a mistake to do all of the proposed removals at once. We can spread removals out in 9.x releases, after users have had a few releases with a choice between old and new and the new alternative is solid.
> >> >
> >> >
> >> > I find it highly depressing that we can't, *in a major release*, manage to get rid of our deprecations -- particularly for code that has a new home and is packaged in a form that is trivial to install (thanks to our new awesome package manager). I'm sympathetic to waiting to delete until *after* there is an actual package ready at that time (rather than just the promise of one).
> >> >
> >> > Also, users generally are cautious on performing a major version upgrade. There's time.
> >> >
> >> > ~ David Smiley
> >> > Apache Lucene/Solr Search Developer
> >> > http://www.linkedin.com/in/davidwsmiley
> >> >
> >> >
> >> > On Wed, Aug 12, 2020 at 4:06 AM Jan Høydahl <ja...@cominvent.com> wrote:
> >> >>
> >> >> I edited the page to introduce the (super important) Solr TLP split into the roadmap.
> >> >> Also added a rough timeframe and a «major theme» for each release above the issue table.
> >> >> I added 8.8 and 9.1 as I think it is important to track what gets done just before 9.0 and what can be deferred to after 9.0.
> >> >>
> >> >> It has been proposed on the list to NOT rip out all deprecations in 9.0, but allow users to upgrade to 9.0 with e.g. SolrCell still available, and then have yet some time to change their processes to adapt to the new way of doing stuff. I like that proposal. Sure, 9.0 will remove lots of deprecated code, but I think it is a mistake to do all of the proposed removals at once. We can spread removals out in 9.x releases, after users have had a few releases with a choice between old and new and the new alternative is solid.
> >> >>
> >> >> Thanks Gus for taking ownership and suggesting a process! Feel free to rework what I edited into a structure you see more fit.
> >> >>
> >> >> Jan
> >> >>
> >> >> 11. aug. 2020 kl. 18:51 skrev Gus Heck <gu...@gmail.com>:
> >> >>
> >> >> I was thinking that level of detail is in the Jira... I don't see any reason for things to disappear (in fact rejected should go in a rejected list for future reference.)
> >> >>
> >> >> On Tue, Aug 11, 2020 at 12:04 PM Ilan Ginzburg <il...@gmail.com> wrote:
> >> >>>
> >> >>> 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 <gu...@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 <ic...@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 <ja...@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 <no...@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 <ja...@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 <da...@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-unsubscribe@lucene.apache.org
> >> >>>>>>
> >> >>>>>>
> >> >>>>>> > For additional commands, e-mail: dev-help@lucene.apache.org
> >> >>>>>>
> >> >>>>>>
> >> >>>>>> >
> >> >>>>>>
> >> >>>>>>
> >> >>>>>>
> >> >>>>>>
> >> >>>>>>
> >> >>>>>>
> >> >>>>>>
> >> >>>>>>
> >> >>>>>> ---------------------------------------------------------------------
> >> >>>>>>
> >> >>>>>>
> >> >>>>>> To unsubscribe, e-mail: dev-unsubscribe@lucene.apache.org
> >> >>>>>>
> >> >>>>>>
> >> >>>>>> For additional commands, e-mail: dev-help@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-unsubscribe@lucene.apache.org
> >> For additional commands, e-mail: dev-help@lucene.apache.org
> >>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@lucene.apache.org
> For additional commands, e-mail: dev-help@lucene.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@lucene.apache.org
For additional commands, e-mail: dev-help@lucene.apache.org
Re: RoadMap?
Posted by Ishan Chattopadhyaya <ic...@gmail.com>.
It does start. It is broken because it is fraught with dangers of users
shooting themselves in their feet. Some context here:
https://issues.apache.org/jira/browse/SOLR-14616?focusedCommentId=17153129&page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-17153129
On Fri, Aug 28, 2020 at 4:52 AM Alexandre Rafalovitch <ar...@gmail.com>
wrote:
> If CDCR is actively broken (does not start?), then isn't it
> effectively deprecated from the last version that did not work? And if
> it is not going to be maintained, then isn't the 'latest' version is
> whichever we still did not delete it in. Because a broken feature is
> only worth keeping in, if we ever plan to fix it.
>
> We have been through the same with UIMA, if I recall. It was broken
> for a bit and then when I pulled it, ONE person got all upset.
> SOLR-11694
>
> Regards,
> Alex
> Ps. I don't know the degree of 'broken' of this specific feature. So,
> I am mostly talking practical principles here.
>
> On Thu, 27 Aug 2020 at 19:03, Ishan Chattopadhyaya
> <ic...@gmail.com> wrote:
> >
> > > I find it highly depressing that we can't, *in a major release*,
> manage to get rid of our deprecations -- particularly for code that has a
> new home and is packaged in a form that is trivial to install (thanks to
> our new awesome package manager).
> >
> > I'm not sure why you think "we can't". I can't even remember a single
> committer standing in the way of removing those *that already have a
> package*. However, there's a backlash against removing CDCR even though
> there is no one volunteering to support it (as a package) and it is clearly
> broken, which is what totally puzzles me.
> https://issues.apache.org/jira/browse/SOLR-14616
> >
> > On Fri, Aug 28, 2020 at 4:19 AM Alexandre Rafalovitch <
> arafalov@gmail.com> wrote:
> >>
> >> Well, I have created SOLR-14783 (Remove DIH from 9.0) and am busily
> >> learning magic gradle commands to make that happen without leaving
> >> behind random crumbs. Once that lands, I will do Jira search on all
> >> DIH still-open tasks after that and close them pointing to the said
> >> Jira.
> >>
> >> So, I guess somebody better -1 the Jira if they really want that one
> >> to stay until ... ? And then read very carefully through SIP-10 of
> >> which, this is just a first step.
> >>
> >> In general, maybe we can manage to do so many new features and cleanup
> >> in 9 that will make Solr TLP look like a great Big Bang moment...
> >>
> >> And it will probably take a little longer to achieve that, so the -
> >> effective - deprecation schedule would still be ok.
> >>
> >> Regards,
> >> Alex.
> >>
> >> On Thu, 27 Aug 2020 at 18:35, David Smiley <ds...@apache.org> wrote:
> >> >>
> >> >> It has been proposed on the list to NOT rip out all deprecations in
> 9.0, but allow users to upgrade to 9.0 with e.g. SolrCell still available,
> and then have yet some time to change their processes to adapt to the new
> way of doing stuff. I like that proposal. Sure, 9.0 will remove lots of
> deprecated code, but I think it is a mistake to do all of the proposed
> removals at once. We can spread removals out in 9.x releases, after users
> have had a few releases with a choice between old and new and the new
> alternative is solid.
> >> >
> >> >
> >> > I find it highly depressing that we can't, *in a major release*,
> manage to get rid of our deprecations -- particularly for code that has a
> new home and is packaged in a form that is trivial to install (thanks to
> our new awesome package manager). I'm sympathetic to waiting to delete
> until *after* there is an actual package ready at that time (rather than
> just the promise of one).
> >> >
> >> > Also, users generally are cautious on performing a major version
> upgrade. There's time.
> >> >
> >> > ~ David Smiley
> >> > Apache Lucene/Solr Search Developer
> >> > http://www.linkedin.com/in/davidwsmiley
> >> >
> >> >
> >> > On Wed, Aug 12, 2020 at 4:06 AM Jan Høydahl <ja...@cominvent.com>
> wrote:
> >> >>
> >> >> I edited the page to introduce the (super important) Solr TLP split
> into the roadmap.
> >> >> Also added a rough timeframe and a «major theme» for each release
> above the issue table.
> >> >> I added 8.8 and 9.1 as I think it is important to track what gets
> done just before 9.0 and what can be deferred to after 9.0.
> >> >>
> >> >> It has been proposed on the list to NOT rip out all deprecations in
> 9.0, but allow users to upgrade to 9.0 with e.g. SolrCell still available,
> and then have yet some time to change their processes to adapt to the new
> way of doing stuff. I like that proposal. Sure, 9.0 will remove lots of
> deprecated code, but I think it is a mistake to do all of the proposed
> removals at once. We can spread removals out in 9.x releases, after users
> have had a few releases with a choice between old and new and the new
> alternative is solid.
> >> >>
> >> >> Thanks Gus for taking ownership and suggesting a process! Feel free
> to rework what I edited into a structure you see more fit.
> >> >>
> >> >> Jan
> >> >>
> >> >> 11. aug. 2020 kl. 18:51 skrev Gus Heck <gu...@gmail.com>:
> >> >>
> >> >> I was thinking that level of detail is in the Jira... I don't see
> any reason for things to disappear (in fact rejected should go in a
> rejected list for future reference.)
> >> >>
> >> >> On Tue, Aug 11, 2020 at 12:04 PM Ilan Ginzburg <il...@gmail.com>
> wrote:
> >> >>>
> >> >>> 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 <gu...@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 <
> ichattopadhyaya@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.asf@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.paul@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.asf@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.weiss@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-unsubscribe@lucene.apache.org
> >> >>>>>>
> >> >>>>>>
> >> >>>>>> > For additional commands, e-mail: dev-help@lucene.apache.org
> >> >>>>>>
> >> >>>>>>
> >> >>>>>> >
> >> >>>>>>
> >> >>>>>>
> >> >>>>>>
> >> >>>>>>
> >> >>>>>>
> >> >>>>>>
> >> >>>>>>
> >> >>>>>>
> >> >>>>>>
> ---------------------------------------------------------------------
> >> >>>>>>
> >> >>>>>>
> >> >>>>>> To unsubscribe, e-mail: dev-unsubscribe@lucene.apache.org
> >> >>>>>>
> >> >>>>>>
> >> >>>>>> For additional commands, e-mail: dev-help@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-unsubscribe@lucene.apache.org
> >> For additional commands, e-mail: dev-help@lucene.apache.org
> >>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@lucene.apache.org
> For additional commands, e-mail: dev-help@lucene.apache.org
>
>
Re: RoadMap?
Posted by Alexandre Rafalovitch <ar...@gmail.com>.
If CDCR is actively broken (does not start?), then isn't it
effectively deprecated from the last version that did not work? And if
it is not going to be maintained, then isn't the 'latest' version is
whichever we still did not delete it in. Because a broken feature is
only worth keeping in, if we ever plan to fix it.
We have been through the same with UIMA, if I recall. It was broken
for a bit and then when I pulled it, ONE person got all upset.
SOLR-11694
Regards,
Alex
Ps. I don't know the degree of 'broken' of this specific feature. So,
I am mostly talking practical principles here.
On Thu, 27 Aug 2020 at 19:03, Ishan Chattopadhyaya
<ic...@gmail.com> wrote:
>
> > I find it highly depressing that we can't, *in a major release*, manage to get rid of our deprecations -- particularly for code that has a new home and is packaged in a form that is trivial to install (thanks to our new awesome package manager).
>
> I'm not sure why you think "we can't". I can't even remember a single committer standing in the way of removing those *that already have a package*. However, there's a backlash against removing CDCR even though there is no one volunteering to support it (as a package) and it is clearly broken, which is what totally puzzles me. https://issues.apache.org/jira/browse/SOLR-14616
>
> On Fri, Aug 28, 2020 at 4:19 AM Alexandre Rafalovitch <ar...@gmail.com> wrote:
>>
>> Well, I have created SOLR-14783 (Remove DIH from 9.0) and am busily
>> learning magic gradle commands to make that happen without leaving
>> behind random crumbs. Once that lands, I will do Jira search on all
>> DIH still-open tasks after that and close them pointing to the said
>> Jira.
>>
>> So, I guess somebody better -1 the Jira if they really want that one
>> to stay until ... ? And then read very carefully through SIP-10 of
>> which, this is just a first step.
>>
>> In general, maybe we can manage to do so many new features and cleanup
>> in 9 that will make Solr TLP look like a great Big Bang moment...
>>
>> And it will probably take a little longer to achieve that, so the -
>> effective - deprecation schedule would still be ok.
>>
>> Regards,
>> Alex.
>>
>> On Thu, 27 Aug 2020 at 18:35, David Smiley <ds...@apache.org> wrote:
>> >>
>> >> It has been proposed on the list to NOT rip out all deprecations in 9.0, but allow users to upgrade to 9.0 with e.g. SolrCell still available, and then have yet some time to change their processes to adapt to the new way of doing stuff. I like that proposal. Sure, 9.0 will remove lots of deprecated code, but I think it is a mistake to do all of the proposed removals at once. We can spread removals out in 9.x releases, after users have had a few releases with a choice between old and new and the new alternative is solid.
>> >
>> >
>> > I find it highly depressing that we can't, *in a major release*, manage to get rid of our deprecations -- particularly for code that has a new home and is packaged in a form that is trivial to install (thanks to our new awesome package manager). I'm sympathetic to waiting to delete until *after* there is an actual package ready at that time (rather than just the promise of one).
>> >
>> > Also, users generally are cautious on performing a major version upgrade. There's time.
>> >
>> > ~ David Smiley
>> > Apache Lucene/Solr Search Developer
>> > http://www.linkedin.com/in/davidwsmiley
>> >
>> >
>> > On Wed, Aug 12, 2020 at 4:06 AM Jan Høydahl <ja...@cominvent.com> wrote:
>> >>
>> >> I edited the page to introduce the (super important) Solr TLP split into the roadmap.
>> >> Also added a rough timeframe and a «major theme» for each release above the issue table.
>> >> I added 8.8 and 9.1 as I think it is important to track what gets done just before 9.0 and what can be deferred to after 9.0.
>> >>
>> >> It has been proposed on the list to NOT rip out all deprecations in 9.0, but allow users to upgrade to 9.0 with e.g. SolrCell still available, and then have yet some time to change their processes to adapt to the new way of doing stuff. I like that proposal. Sure, 9.0 will remove lots of deprecated code, but I think it is a mistake to do all of the proposed removals at once. We can spread removals out in 9.x releases, after users have had a few releases with a choice between old and new and the new alternative is solid.
>> >>
>> >> Thanks Gus for taking ownership and suggesting a process! Feel free to rework what I edited into a structure you see more fit.
>> >>
>> >> Jan
>> >>
>> >> 11. aug. 2020 kl. 18:51 skrev Gus Heck <gu...@gmail.com>:
>> >>
>> >> I was thinking that level of detail is in the Jira... I don't see any reason for things to disappear (in fact rejected should go in a rejected list for future reference.)
>> >>
>> >> On Tue, Aug 11, 2020 at 12:04 PM Ilan Ginzburg <il...@gmail.com> wrote:
>> >>>
>> >>> 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 <gu...@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 <ic...@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 <ja...@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 <no...@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 <ja...@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 <da...@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-unsubscribe@lucene.apache.org
>> >>>>>>
>> >>>>>>
>> >>>>>> > For additional commands, e-mail: dev-help@lucene.apache.org
>> >>>>>>
>> >>>>>>
>> >>>>>> >
>> >>>>>>
>> >>>>>>
>> >>>>>>
>> >>>>>>
>> >>>>>>
>> >>>>>>
>> >>>>>>
>> >>>>>>
>> >>>>>> ---------------------------------------------------------------------
>> >>>>>>
>> >>>>>>
>> >>>>>> To unsubscribe, e-mail: dev-unsubscribe@lucene.apache.org
>> >>>>>>
>> >>>>>>
>> >>>>>> For additional commands, e-mail: dev-help@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-unsubscribe@lucene.apache.org
>> For additional commands, e-mail: dev-help@lucene.apache.org
>>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@lucene.apache.org
For additional commands, e-mail: dev-help@lucene.apache.org
Re: RoadMap?
Posted by Ishan Chattopadhyaya <ic...@gmail.com>.
> I find it highly depressing that we can't, *in a major release*, manage
to get rid of our deprecations -- particularly for code that has a new home
and is packaged in a form that is trivial to install (thanks to our new
awesome package manager).
I'm not sure why you think "we can't". I can't even remember a single
committer standing in the way of removing those *that already have a
package*. However, there's a backlash against removing CDCR even though
there is no one volunteering to support it (as a package) and it is clearly
broken, which is what totally puzzles me.
https://issues.apache.org/jira/browse/SOLR-14616
On Fri, Aug 28, 2020 at 4:19 AM Alexandre Rafalovitch <ar...@gmail.com>
wrote:
> Well, I have created SOLR-14783 (Remove DIH from 9.0) and am busily
> learning magic gradle commands to make that happen without leaving
> behind random crumbs. Once that lands, I will do Jira search on all
> DIH still-open tasks after that and close them pointing to the said
> Jira.
>
> So, I guess somebody better -1 the Jira if they really want that one
> to stay until ... ? And then read very carefully through SIP-10 of
> which, this is just a first step.
>
> In general, maybe we can manage to do so many new features and cleanup
> in 9 that will make Solr TLP look like a great Big Bang moment...
>
> And it will probably take a little longer to achieve that, so the -
> effective - deprecation schedule would still be ok.
>
> Regards,
> Alex.
>
> On Thu, 27 Aug 2020 at 18:35, David Smiley <ds...@apache.org> wrote:
> >>
> >> It has been proposed on the list to NOT rip out all deprecations in
> 9.0, but allow users to upgrade to 9.0 with e.g. SolrCell still available,
> and then have yet some time to change their processes to adapt to the new
> way of doing stuff. I like that proposal. Sure, 9.0 will remove lots of
> deprecated code, but I think it is a mistake to do all of the proposed
> removals at once. We can spread removals out in 9.x releases, after users
> have had a few releases with a choice between old and new and the new
> alternative is solid.
> >
> >
> > I find it highly depressing that we can't, *in a major release*, manage
> to get rid of our deprecations -- particularly for code that has a new home
> and is packaged in a form that is trivial to install (thanks to our new
> awesome package manager). I'm sympathetic to waiting to delete until
> *after* there is an actual package ready at that time (rather than just the
> promise of one).
> >
> > Also, users generally are cautious on performing a major version
> upgrade. There's time.
> >
> > ~ David Smiley
> > Apache Lucene/Solr Search Developer
> > http://www.linkedin.com/in/davidwsmiley
> >
> >
> > On Wed, Aug 12, 2020 at 4:06 AM Jan Høydahl <ja...@cominvent.com>
> wrote:
> >>
> >> I edited the page to introduce the (super important) Solr TLP split
> into the roadmap.
> >> Also added a rough timeframe and a «major theme» for each release above
> the issue table.
> >> I added 8.8 and 9.1 as I think it is important to track what gets done
> just before 9.0 and what can be deferred to after 9.0.
> >>
> >> It has been proposed on the list to NOT rip out all deprecations in
> 9.0, but allow users to upgrade to 9.0 with e.g. SolrCell still available,
> and then have yet some time to change their processes to adapt to the new
> way of doing stuff. I like that proposal. Sure, 9.0 will remove lots of
> deprecated code, but I think it is a mistake to do all of the proposed
> removals at once. We can spread removals out in 9.x releases, after users
> have had a few releases with a choice between old and new and the new
> alternative is solid.
> >>
> >> Thanks Gus for taking ownership and suggesting a process! Feel free to
> rework what I edited into a structure you see more fit.
> >>
> >> Jan
> >>
> >> 11. aug. 2020 kl. 18:51 skrev Gus Heck <gu...@gmail.com>:
> >>
> >> I was thinking that level of detail is in the Jira... I don't see any
> reason for things to disappear (in fact rejected should go in a rejected
> list for future reference.)
> >>
> >> On Tue, Aug 11, 2020 at 12:04 PM Ilan Ginzburg <il...@gmail.com>
> wrote:
> >>>
> >>> 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 <gu...@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 <
> ichattopadhyaya@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 <ja...@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 <no...@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 <ja...@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.weiss@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-unsubscribe@lucene.apache.org
> >>>>>>
> >>>>>>
> >>>>>> > For additional commands, e-mail: dev-help@lucene.apache.org
> >>>>>>
> >>>>>>
> >>>>>> >
> >>>>>>
> >>>>>>
> >>>>>>
> >>>>>>
> >>>>>>
> >>>>>>
> >>>>>>
> >>>>>>
> >>>>>>
> ---------------------------------------------------------------------
> >>>>>>
> >>>>>>
> >>>>>> To unsubscribe, e-mail: dev-unsubscribe@lucene.apache.org
> >>>>>>
> >>>>>>
> >>>>>> For additional commands, e-mail: dev-help@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-unsubscribe@lucene.apache.org
> For additional commands, e-mail: dev-help@lucene.apache.org
>
>
Re: RoadMap?
Posted by Alexandre Rafalovitch <ar...@gmail.com>.
Well, I have created SOLR-14783 (Remove DIH from 9.0) and am busily
learning magic gradle commands to make that happen without leaving
behind random crumbs. Once that lands, I will do Jira search on all
DIH still-open tasks after that and close them pointing to the said
Jira.
So, I guess somebody better -1 the Jira if they really want that one
to stay until ... ? And then read very carefully through SIP-10 of
which, this is just a first step.
In general, maybe we can manage to do so many new features and cleanup
in 9 that will make Solr TLP look like a great Big Bang moment...
And it will probably take a little longer to achieve that, so the -
effective - deprecation schedule would still be ok.
Regards,
Alex.
On Thu, 27 Aug 2020 at 18:35, David Smiley <ds...@apache.org> wrote:
>>
>> It has been proposed on the list to NOT rip out all deprecations in 9.0, but allow users to upgrade to 9.0 with e.g. SolrCell still available, and then have yet some time to change their processes to adapt to the new way of doing stuff. I like that proposal. Sure, 9.0 will remove lots of deprecated code, but I think it is a mistake to do all of the proposed removals at once. We can spread removals out in 9.x releases, after users have had a few releases with a choice between old and new and the new alternative is solid.
>
>
> I find it highly depressing that we can't, *in a major release*, manage to get rid of our deprecations -- particularly for code that has a new home and is packaged in a form that is trivial to install (thanks to our new awesome package manager). I'm sympathetic to waiting to delete until *after* there is an actual package ready at that time (rather than just the promise of one).
>
> Also, users generally are cautious on performing a major version upgrade. There's time.
>
> ~ David Smiley
> Apache Lucene/Solr Search Developer
> http://www.linkedin.com/in/davidwsmiley
>
>
> On Wed, Aug 12, 2020 at 4:06 AM Jan Høydahl <ja...@cominvent.com> wrote:
>>
>> I edited the page to introduce the (super important) Solr TLP split into the roadmap.
>> Also added a rough timeframe and a «major theme» for each release above the issue table.
>> I added 8.8 and 9.1 as I think it is important to track what gets done just before 9.0 and what can be deferred to after 9.0.
>>
>> It has been proposed on the list to NOT rip out all deprecations in 9.0, but allow users to upgrade to 9.0 with e.g. SolrCell still available, and then have yet some time to change their processes to adapt to the new way of doing stuff. I like that proposal. Sure, 9.0 will remove lots of deprecated code, but I think it is a mistake to do all of the proposed removals at once. We can spread removals out in 9.x releases, after users have had a few releases with a choice between old and new and the new alternative is solid.
>>
>> Thanks Gus for taking ownership and suggesting a process! Feel free to rework what I edited into a structure you see more fit.
>>
>> Jan
>>
>> 11. aug. 2020 kl. 18:51 skrev Gus Heck <gu...@gmail.com>:
>>
>> I was thinking that level of detail is in the Jira... I don't see any reason for things to disappear (in fact rejected should go in a rejected list for future reference.)
>>
>> On Tue, Aug 11, 2020 at 12:04 PM Ilan Ginzburg <il...@gmail.com> wrote:
>>>
>>> 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 <gu...@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 <ic...@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 <ja...@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 <no...@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 <ja...@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 <da...@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-unsubscribe@lucene.apache.org
>>>>>>
>>>>>>
>>>>>> > For additional commands, e-mail: dev-help@lucene.apache.org
>>>>>>
>>>>>>
>>>>>> >
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>> ---------------------------------------------------------------------
>>>>>>
>>>>>>
>>>>>> To unsubscribe, e-mail: dev-unsubscribe@lucene.apache.org
>>>>>>
>>>>>>
>>>>>> For additional commands, e-mail: dev-help@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-unsubscribe@lucene.apache.org
For additional commands, e-mail: dev-help@lucene.apache.org
Re: RoadMap?
Posted by David Smiley <ds...@apache.org>.
>
> It has been proposed on the list to NOT rip out all deprecations in 9.0,
> but allow users to upgrade to 9.0 with e.g. SolrCell still available, and
> then have yet some time to change their processes to adapt to the new way
> of doing stuff. I like that proposal. Sure, 9.0 will remove lots of
> deprecated code, but I think it is a mistake to do all of the proposed
> removals at once. We can spread removals out in 9.x releases, after users
> have had a few releases with a choice between old and new and the new
> alternative is solid.
>
I find it highly depressing that we can't, *in a major release*, manage to
get rid of our deprecations -- particularly for code that has a new home
and is packaged in a form that is trivial to install (thanks to our new
awesome package manager). I'm sympathetic to waiting to delete until
*after* there is an actual package ready at that time (rather than just the
promise of one).
Also, users generally are cautious on performing a major version upgrade.
There's time.
~ David Smiley
Apache Lucene/Solr Search Developer
http://www.linkedin.com/in/davidwsmiley
On Wed, Aug 12, 2020 at 4:06 AM Jan Høydahl <ja...@cominvent.com> wrote:
> I edited the page to introduce the (super important) Solr TLP split into
> the roadmap.
> Also added a rough timeframe and a «major theme» for each release above
> the issue table.
> I added 8.8 and 9.1 as I think it is important to track what gets done
> just before 9.0 and what can be deferred to after 9.0.
>
> It has been proposed on the list to NOT rip out all deprecations in 9.0,
> but allow users to upgrade to 9.0 with e.g. SolrCell still available, and
> then have yet some time to change their processes to adapt to the new way
> of doing stuff. I like that proposal. Sure, 9.0 will remove lots of
> deprecated code, but I think it is a mistake to do all of the proposed
> removals at once. We can spread removals out in 9.x releases, after users
> have had a few releases with a choice between old and new and the new
> alternative is solid.
>
> Thanks Gus for taking ownership and suggesting a process! Feel free to
> rework what I edited into a structure you see more fit.
>
> Jan
>
> 11. aug. 2020 kl. 18:51 skrev Gus Heck <gu...@gmail.com>:
>
> I was thinking that level of detail is in the Jira... I don't see any
> reason for things to disappear (in fact rejected should go in a rejected
> list for future reference.)
>
> On Tue, Aug 11, 2020 at 12:04 PM Ilan Ginzburg <il...@gmail.com> wrote:
>
>> 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 <gu...@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 <
>>> ichattopadhyaya@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 <ja...@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 <no...@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 <ja...@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 <da...@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-unsubscribe@lucene.apache.org
>>>>>
>>>>>
>>>>> > For additional commands, e-mail: dev-help@lucene.apache.org
>>>>>
>>>>>
>>>>> >
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>> ---------------------------------------------------------------------
>>>>>
>>>>>
>>>>> To unsubscribe, e-mail: dev-unsubscribe@lucene.apache.org
>>>>>
>>>>>
>>>>> For additional commands, e-mail: dev-help@lucene.apache.org
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>
>>>>
>>>
>>> --
>>> http://www.needhamsoftware.com (work)
>>> http://www.the111shift.com (play)
>>>
>>>
>>>
>
> --
> http://www.needhamsoftware.com (work)
> http://www.the111shift.com (play)
>
>
>
Re: RoadMap?
Posted by Jason Gerlowski <ge...@gmail.com>.
I agree with the approach Jan voiced - that at least some of these
features should appear in 9.0 as deprecated to give users more time.
That said, maybe discussing what to do around these features should be
its own thread or should be taken back to some of the specific jiras
where there's already been some discussion (e.g. SOLR-14616). It just
seems likely to hijack this thread away from other discussions (how to
manage/handle our new Roadmap page).
On Wed, Aug 12, 2020 at 9:35 AM Ishan Chattopadhyaya
<ic...@gmail.com> wrote:
>
> > It has been proposed on the list to NOT rip out all deprecations in 9.0, but allow users to
> > upgrade to 9.0 with e.g. SolrCell still available, and then have yet some time to change their
> > processes to adapt to the new way of doing stuff. I like that proposal. Sure, 9.0 will remove lots
> > of deprecated code, but I think it is a mistake to do all of the proposed removals at once. We
> > can spread removals out in 9.x releases, after users have had a few releases with a choice between
> > old and new and the new alternative is solid.
>
> I support the DIH, autoscaling and CDCR going away in 9.0, rest of the things can just move into first party packages and continue to be part of the distribution. Does that make sense, Jan?
>
> On Wed, Aug 12, 2020 at 1:36 PM Jan Høydahl <ja...@cominvent.com> wrote:
>>
>> I edited the page to introduce the (super important) Solr TLP split into the roadmap.
>> Also added a rough timeframe and a «major theme» for each release above the issue table.
>> I added 8.8 and 9.1 as I think it is important to track what gets done just before 9.0 and what can be deferred to after 9.0.
>>
>> It has been proposed on the list to NOT rip out all deprecations in 9.0, but allow users to upgrade to 9.0 with e.g. SolrCell still available, and then have yet some time to change their processes to adapt to the new way of doing stuff. I like that proposal. Sure, 9.0 will remove lots of deprecated code, but I think it is a mistake to do all of the proposed removals at once. We can spread removals out in 9.x releases, after users have had a few releases with a choice between old and new and the new alternative is solid.
>>
>> Thanks Gus for taking ownership and suggesting a process! Feel free to rework what I edited into a structure you see more fit.
>>
>> Jan
>>
>> 11. aug. 2020 kl. 18:51 skrev Gus Heck <gu...@gmail.com>:
>>
>> I was thinking that level of detail is in the Jira... I don't see any reason for things to disappear (in fact rejected should go in a rejected list for future reference.)
>>
>> On Tue, Aug 11, 2020 at 12:04 PM Ilan Ginzburg <il...@gmail.com> wrote:
>>>
>>> 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 <gu...@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 <ic...@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 <ja...@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 <no...@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 <ja...@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 <da...@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-unsubscribe@lucene.apache.org
>>>>>>
>>>>>>
>>>>>> > For additional commands, e-mail: dev-help@lucene.apache.org
>>>>>>
>>>>>>
>>>>>> >
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>> ---------------------------------------------------------------------
>>>>>>
>>>>>>
>>>>>> To unsubscribe, e-mail: dev-unsubscribe@lucene.apache.org
>>>>>>
>>>>>>
>>>>>> For additional commands, e-mail: dev-help@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-unsubscribe@lucene.apache.org
For additional commands, e-mail: dev-help@lucene.apache.org
Re: RoadMap?
Posted by Ishan Chattopadhyaya <ic...@gmail.com>.
> It has been proposed on the list to NOT rip out all deprecations in 9.0,
but allow users to
> upgrade to 9.0 with e.g. SolrCell still available, and then have yet some
time to change their
> processes to adapt to the new way of doing stuff. I like that proposal.
Sure, 9.0 will remove lots
> of deprecated code, but I think it is a mistake to do all of the proposed
removals at once. We
> can spread removals out in 9.x releases, after users have had a few
releases with a choice between
> old and new and the new alternative is solid.
I support the DIH, autoscaling and CDCR going away in 9.0, rest of the
things can just move into first party packages and continue to be part of
the distribution. Does that make sense, Jan?
On Wed, Aug 12, 2020 at 1:36 PM Jan Høydahl <ja...@cominvent.com> wrote:
> I edited the page to introduce the (super important) Solr TLP split into
> the roadmap.
> Also added a rough timeframe and a «major theme» for each release above
> the issue table.
> I added 8.8 and 9.1 as I think it is important to track what gets done
> just before 9.0 and what can be deferred to after 9.0.
>
> It has been proposed on the list to NOT rip out all deprecations in 9.0,
> but allow users to upgrade to 9.0 with e.g. SolrCell still available, and
> then have yet some time to change their processes to adapt to the new way
> of doing stuff. I like that proposal. Sure, 9.0 will remove lots of
> deprecated code, but I think it is a mistake to do all of the proposed
> removals at once. We can spread removals out in 9.x releases, after users
> have had a few releases with a choice between old and new and the new
> alternative is solid.
>
> Thanks Gus for taking ownership and suggesting a process! Feel free to
> rework what I edited into a structure you see more fit.
>
> Jan
>
> 11. aug. 2020 kl. 18:51 skrev Gus Heck <gu...@gmail.com>:
>
> I was thinking that level of detail is in the Jira... I don't see any
> reason for things to disappear (in fact rejected should go in a rejected
> list for future reference.)
>
> On Tue, Aug 11, 2020 at 12:04 PM Ilan Ginzburg <il...@gmail.com> wrote:
>
>> 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 <gu...@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 <
>>> ichattopadhyaya@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 <ja...@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 <no...@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 <ja...@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 <da...@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-unsubscribe@lucene.apache.org
>>>>>
>>>>>
>>>>> > For additional commands, e-mail: dev-help@lucene.apache.org
>>>>>
>>>>>
>>>>> >
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>> ---------------------------------------------------------------------
>>>>>
>>>>>
>>>>> To unsubscribe, e-mail: dev-unsubscribe@lucene.apache.org
>>>>>
>>>>>
>>>>> For additional commands, e-mail: dev-help@lucene.apache.org
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>
>>>>
>>>
>>> --
>>> http://www.needhamsoftware.com (work)
>>> http://www.the111shift.com (play)
>>>
>>>
>>>
>
> --
> http://www.needhamsoftware.com (work)
> http://www.the111shift.com (play)
>
>
>
Re: RoadMap?
Posted by Jan Høydahl <ja...@cominvent.com>.
I edited the page to introduce the (super important) Solr TLP split into the roadmap.
Also added a rough timeframe and a «major theme» for each release above the issue table.
I added 8.8 and 9.1 as I think it is important to track what gets done just before 9.0 and what can be deferred to after 9.0.
It has been proposed on the list to NOT rip out all deprecations in 9.0, but allow users to upgrade to 9.0 with e.g. SolrCell still available, and then have yet some time to change their processes to adapt to the new way of doing stuff. I like that proposal. Sure, 9.0 will remove lots of deprecated code, but I think it is a mistake to do all of the proposed removals at once. We can spread removals out in 9.x releases, after users have had a few releases with a choice between old and new and the new alternative is solid.
Thanks Gus for taking ownership and suggesting a process! Feel free to rework what I edited into a structure you see more fit.
Jan
> 11. aug. 2020 kl. 18:51 skrev Gus Heck <gu...@gmail.com>:
>
> I was thinking that level of detail is in the Jira... I don't see any reason for things to disappear (in fact rejected should go in a rejected list for future reference.)
>
> On Tue, Aug 11, 2020 at 12:04 PM Ilan Ginzburg <ilansolr@gmail.com <ma...@gmail.com>> wrote:
> 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.heck@gmail.com <ma...@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 <ichattopadhyaya@gmail.com <ma...@gmail.com>> wrote:
> I've created a placeholder document here: https://cwiki.apache.org/confluence/display/SOLR/Roadmap <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.asf@cominvent.com <ma...@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.paul@gmail.com <ma...@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.asf@cominvent.com <ma...@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.weiss@gmail.com <ma...@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-unsubscribe@lucene.apache.org <ma...@lucene.apache.org>
>
>
> > For additional commands, e-mail: dev-help@lucene.apache.org <ma...@lucene.apache.org>
>
>
> >
>
>
>
>
>
>
>
>
> ---------------------------------------------------------------------
>
>
> To unsubscribe, e-mail: dev-unsubscribe@lucene.apache.org <ma...@lucene.apache.org>
>
>
> For additional commands, e-mail: dev-help@lucene.apache.org <ma...@lucene.apache.org>
>
>
>
>
>
>
>
>
>
> --
> http://www.needhamsoftware.com <http://www.needhamsoftware.com/> (work)
> http://www.the111shift.com <http://www.the111shift.com/> (play)
>
>
>
>
> --
> http://www.needhamsoftware.com <http://www.needhamsoftware.com/> (work)
> http://www.the111shift.com <http://www.the111shift.com/> (play)
Re: RoadMap?
Posted by Gus Heck <gu...@gmail.com>.
I was thinking that level of detail is in the Jira... I don't see any
reason for things to disappear (in fact rejected should go in a rejected
list for future reference.)
On Tue, Aug 11, 2020 at 12:04 PM Ilan Ginzburg <il...@gmail.com> wrote:
> 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 <gu...@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 <
>> ichattopadhyaya@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 <ja...@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 <no...@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 <ja...@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 <da...@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-unsubscribe@lucene.apache.org
>>>>
>>>>
>>>> > For additional commands, e-mail: dev-help@lucene.apache.org
>>>>
>>>>
>>>> >
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>
>>>> ---------------------------------------------------------------------
>>>>
>>>>
>>>> To unsubscribe, e-mail: dev-unsubscribe@lucene.apache.org
>>>>
>>>>
>>>> For additional commands, e-mail: dev-help@lucene.apache.org
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>
>>>
>>>
>>
>> --
>> http://www.needhamsoftware.com (work)
>> http://www.the111shift.com (play)
>>
>>
>>
--
http://www.needhamsoftware.com (work)
http://www.the111shift.com (play)
Re: RoadMap?
Posted by Ilan Ginzburg <il...@gmail.com>.
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 <gu...@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 <
> ichattopadhyaya@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 <ja...@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 <no...@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 <ja...@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 <da...@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-unsubscribe@lucene.apache.org
>>>
>>>
>>> > For additional commands, e-mail: dev-help@lucene.apache.org
>>>
>>>
>>> >
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>> ---------------------------------------------------------------------
>>>
>>>
>>> To unsubscribe, e-mail: dev-unsubscribe@lucene.apache.org
>>>
>>>
>>> For additional commands, e-mail: dev-help@lucene.apache.org
>>>
>>>
>>>
>>>
>>>
>>>
>>
>>
>
> --
> http://www.needhamsoftware.com (work)
> http://www.the111shift.com (play)
>
>
>
Re: RoadMap?
Posted by Gus Heck <gu...@gmail.com>.
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 <
ichattopadhyaya@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 <ja...@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 <no...@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 <ja...@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 <da...@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-unsubscribe@lucene.apache.org
>> > For additional commands, e-mail: dev-help@lucene.apache.org
>> >
>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: dev-unsubscribe@lucene.apache.org
>> For additional commands, e-mail: dev-help@lucene.apache.org
>>
>>
--
http://www.needhamsoftware.com (work)
http://www.the111shift.com (play)
Re: RoadMap?
Posted by Ishan Chattopadhyaya <ic...@gmail.com>.
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 <ja...@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 <no...@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 <ja...@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 <da...@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-unsubscribe@lucene.apache.org
> > For additional commands, e-mail: dev-help@lucene.apache.org
> >
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@lucene.apache.org
> For additional commands, e-mail: dev-help@lucene.apache.org
>
>
Re: RoadMap?
Posted by Jan Høydahl <ja...@cominvent.com>.
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 <no...@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 <ja...@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 <da...@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-unsubscribe@lucene.apache.org
> For additional commands, e-mail: dev-help@lucene.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@lucene.apache.org
For additional commands, e-mail: dev-help@lucene.apache.org
Re: RoadMap?
Posted by Noble Paul <no...@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 <ja...@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 <da...@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-unsubscribe@lucene.apache.org
For additional commands, e-mail: dev-help@lucene.apache.org
Re: RoadMap?
Posted by Jan Høydahl <ja...@cominvent.com>.
+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 <da...@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.
Re: RoadMap?
Posted by Dawid Weiss <da...@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.
Re: RoadMap?
Posted by Cassandra Targett <ca...@gmail.com>.
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 <er...@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 <gu...@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 <gu...@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 <er...@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 <ab...@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 <gu...@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-unsubscribe@lucene.apache.org
> > For additional commands, e-mail: dev-help@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-unsubscribe@lucene.apache.org
> For additional commands, e-mail: dev-help@lucene.apache.org
>
Re: RoadMap?
Posted by Erick Erickson <er...@gmail.com>.
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 <gu...@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 <gu...@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 <er...@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 <ab...@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 <gu...@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-unsubscribe@lucene.apache.org
> For additional commands, e-mail: dev-help@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-unsubscribe@lucene.apache.org
For additional commands, e-mail: dev-help@lucene.apache.org
Re: RoadMap?
Posted by Ishan Chattopadhyaya <ic...@gmail.com>.
> Autoscaling is another big item, but I think we have to put it into
> 9x, it’s a critical (and critically broken) functionality
I think autoscaling has many aspects to it. The only piece that I find
critical to Solr (SolrCloud / core) is reasonable (not super smart) replica
placement. Rest of all autoscaling functionality (and replica placement as
well) should now be built as pluggable components, and preferably as
packages.
On Fri, Jul 3, 2020 at 5:43 AM Ishan Chattopadhyaya <
ichattopadhyaya@gmail.com> wrote:
> > 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 think we should avoid large code drop-ins at all costs. No new CDCR or
> UI code should be part of Solr codebase. Any big, new feature should be
> built as packages.
>
> On Fri, Jul 3, 2020 at 1:49 AM David Smiley <ds...@apache.org> wrote:
>
>> No more JIRA fields please; "Fix Version" is adequate. You can edit an
>> issue after creating it to set the "Fix version" to "master (9.0)"; the
>> issue doesn't have to be resolved yet. I recently had ASF change JIRA so
>> that this field is not editable on creation of the issue because our
>> contributors don't know any better than to put something inappropriate
>> there. But the edit screen works.
>>
>> I think Lucene might release v9 without Solr if Solr is going to drag its
>> feet for too long. Wearing my Lucene hat (er... well shirt), I support
>> that within reason.
>>
>> Agreed on Confluence.
>>
>> ~ David Smiley
>> Apache Lucene/Solr Search Developer
>> http://www.linkedin.com/in/davidwsmiley
>>
>>
>> On Thu, Jul 2, 2020 at 2:30 PM Gus Heck <gu...@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 <gu...@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 <er...@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 <ab...@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 <gu...@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-unsubscribe@lucene.apache.org
>>>>> For additional commands, e-mail: dev-help@lucene.apache.org
>>>>>
>>>>>
>>>>
>>>> --
>>>> http://www.needhamsoftware.com (work)
>>>> http://www.the111shift.com (play)
>>>>
>>>
>>>
>>> --
>>> http://www.needhamsoftware.com (work)
>>> http://www.the111shift.com (play)
>>>
>>
Re: RoadMap?
Posted by Ishan Chattopadhyaya <ic...@gmail.com>.
> 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 think we should avoid large code drop-ins at all costs. No new CDCR or UI
code should be part of Solr codebase. Any big, new feature should be built
as packages.
On Fri, Jul 3, 2020 at 1:49 AM David Smiley <ds...@apache.org> wrote:
> No more JIRA fields please; "Fix Version" is adequate. You can edit an
> issue after creating it to set the "Fix version" to "master (9.0)"; the
> issue doesn't have to be resolved yet. I recently had ASF change JIRA so
> that this field is not editable on creation of the issue because our
> contributors don't know any better than to put something inappropriate
> there. But the edit screen works.
>
> I think Lucene might release v9 without Solr if Solr is going to drag its
> feet for too long. Wearing my Lucene hat (er... well shirt), I support
> that within reason.
>
> Agreed on Confluence.
>
> ~ David Smiley
> Apache Lucene/Solr Search Developer
> http://www.linkedin.com/in/davidwsmiley
>
>
> On Thu, Jul 2, 2020 at 2:30 PM Gus Heck <gu...@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 <gu...@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 <er...@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 <ab...@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 <gu...@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-unsubscribe@lucene.apache.org
>>>> For additional commands, e-mail: dev-help@lucene.apache.org
>>>>
>>>>
>>>
>>> --
>>> http://www.needhamsoftware.com (work)
>>> http://www.the111shift.com (play)
>>>
>>
>>
>> --
>> http://www.needhamsoftware.com (work)
>> http://www.the111shift.com (play)
>>
>
Re: RoadMap?
Posted by David Smiley <ds...@apache.org>.
No more JIRA fields please; "Fix Version" is adequate. You can edit an
issue after creating it to set the "Fix version" to "master (9.0)"; the
issue doesn't have to be resolved yet. I recently had ASF change JIRA so
that this field is not editable on creation of the issue because our
contributors don't know any better than to put something inappropriate
there. But the edit screen works.
I think Lucene might release v9 without Solr if Solr is going to drag its
feet for too long. Wearing my Lucene hat (er... well shirt), I support
that within reason.
Agreed on Confluence.
~ David Smiley
Apache Lucene/Solr Search Developer
http://www.linkedin.com/in/davidwsmiley
On Thu, Jul 2, 2020 at 2:30 PM Gus Heck <gu...@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 <gu...@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 <er...@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 <ab...@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 <gu...@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-unsubscribe@lucene.apache.org
>>> For additional commands, e-mail: dev-help@lucene.apache.org
>>>
>>>
>>
>> --
>> http://www.needhamsoftware.com (work)
>> http://www.the111shift.com (play)
>>
>
>
> --
> http://www.needhamsoftware.com (work)
> http://www.the111shift.com (play)
>
Re: RoadMap?
Posted by Gus Heck <gu...@gmail.com>.
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 <gu...@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 <er...@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 <ab...@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 <gu...@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-unsubscribe@lucene.apache.org
>> For additional commands, e-mail: dev-help@lucene.apache.org
>>
>>
>
> --
> http://www.needhamsoftware.com (work)
> http://www.the111shift.com (play)
>
--
http://www.needhamsoftware.com (work)
http://www.the111shift.com (play)
Re: RoadMap?
Posted by Gus Heck <gu...@gmail.com>.
Jira typically has features for designating what's in a release....
On Thu, Jul 2, 2020 at 1:55 PM Erick Erickson <er...@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 <ab...@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 <gu...@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-unsubscribe@lucene.apache.org
> For additional commands, e-mail: dev-help@lucene.apache.org
>
>
--
http://www.needhamsoftware.com (work)
http://www.the111shift.com (play)
Re: RoadMap?
Posted by Erick Erickson <er...@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.
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 <ab...@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 <gu...@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-unsubscribe@lucene.apache.org
For additional commands, e-mail: dev-help@lucene.apache.org
Re: RoadMap?
Posted by Andrzej Białecki <ab...@getopt.org>.
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 <gu...@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 <https://issues.apache.org/jira/browse/SOLR-13442> and https://issues.apache.org/jira/browse/SOLR-14022 <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 <http://www.needhamsoftware.com/> (work)
> http://www.the111shift.com <http://www.the111shift.com/> (play)