Do we want to pursue an LTS designation?

classic Classic list List threaded Threaded
13 messages Options
Reply | Threaded
Open this post in threaded view
|

Do we want to pursue an LTS designation?

Shawn Heisey-2
We've had somebody on the Solr mailing list asking questions about our
LTS version.

The thing about this is that we don't really HAVE an LTS version.  Our
major version release pace and the way we deal with older branches mean
that a single major version branch is never in a given state for long
enough to really qualify as "long term".

The 7.x branch is in maintenance mode, so most problems that people
encounter with it will only be addressed in a future 8.x version.  In my
mind, that means it doesn't qualify as LTS.  The current stable branch
is always getting new features, which I think disqualifies that branch
for the LTS label.

The tomcat project has an interesting way of determining when support
ends.  Here's a message outlining it:

https://markmail.org/message/6wycxatwzwycmf43

My question is:  Do we want to change what we do here, or are we happy
with the current model?  If we did change it, I'm not completely sure
what that would look like.

Thanks,
Shawn

---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: Do we want to pursue an LTS designation?

Erick Erickson
I have zero interest in having an LTS “policy” that requires any further commitment of my personal time to random people who ask for it but aren’t willing to pay. I consider my non-paid work to Solr a _volunteer_ activity, not something anyone has a right to demand as “support”, long-term or otherwise.

Best,
Erick

> On Nov 13, 2019, at 12:34 PM, Shawn Heisey <[hidden email]> wrote:
>
> We've had somebody on the Solr mailing list asking questions about our LTS version.
>
> The thing about this is that we don't really HAVE an LTS version.  Our major version release pace and the way we deal with older branches mean that a single major version branch is never in a given state for long enough to really qualify as "long term".
>
> The 7.x branch is in maintenance mode, so most problems that people encounter with it will only be addressed in a future 8.x version.  In my mind, that means it doesn't qualify as LTS.  The current stable branch is always getting new features, which I think disqualifies that branch for the LTS label.
>
> The tomcat project has an interesting way of determining when support ends.  Here's a message outlining it:
>
> https://markmail.org/message/6wycxatwzwycmf43
>
> My question is:  Do we want to change what we do here, or are we happy with the current model?  If we did change it, I'm not completely sure what that would look like.
>
> Thanks,
> Shawn
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: [hidden email]
> For additional commands, e-mail: [hidden email]
>


---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: Do we want to pursue an LTS designation?

Adam Walz
It looks like solr 7.7.x is currently designated as the LTS version on the website. https://lucene.apache.org/solr/downloads.html

On Wed, Nov 13, 2019 at 11:36 AM Erick Erickson <[hidden email]> wrote:
I have zero interest in having an LTS “policy” that requires any further commitment of my personal time to random people who ask for it but aren’t willing to pay. I consider my non-paid work to Solr a _volunteer_ activity, not something anyone has a right to demand as “support”, long-term or otherwise.

Best,
Erick

> On Nov 13, 2019, at 12:34 PM, Shawn Heisey <[hidden email]> wrote:
>
> We've had somebody on the Solr mailing list asking questions about our LTS version.
>
> The thing about this is that we don't really HAVE an LTS version.  Our major version release pace and the way we deal with older branches mean that a single major version branch is never in a given state for long enough to really qualify as "long term".
>
> The 7.x branch is in maintenance mode, so most problems that people encounter with it will only be addressed in a future 8.x version.  In my mind, that means it doesn't qualify as LTS.  The current stable branch is always getting new features, which I think disqualifies that branch for the LTS label.
>
> The tomcat project has an interesting way of determining when support ends.  Here's a message outlining it:
>
> https://markmail.org/message/6wycxatwzwycmf43
>
> My question is:  Do we want to change what we do here, or are we happy with the current model?  If we did change it, I'm not completely sure what that would look like.
>
> Thanks,
> Shawn
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: [hidden email]
> For additional commands, e-mail: [hidden email]
>


---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]



--
Adam Walz
Reply | Threaded
Open this post in threaded view
|

Re: Do we want to pursue an LTS designation?

Jan Høydahl / Cominvent
The term LTS is used loosely and we actually do not promise anything. What we say is

7.7.x Version in the previous major release for bugfixes only (LTS)

In practice 7.7.x will now only get critical security related releases and not ordinary bugfixes, unless someone volunteers to RM such a release.
8.x.x will likely get more bugfix releases after release of 9.0 since there is a Java upgrade requirement.

Being the one coining the LTS phrasing I am not opposed to changing it to something else. But through the years we have used that term I have not seen a lot of such requests.

This is probably a good time to challenge one of you to go clone our new website repo at https://github.com/apache/lucene-site, make a change, build the site locally and submit a PR :) It is actually quite pleasant!

--
Jan Høydahl, search solution architect
Cominvent AS - www.cominvent.com

13. nov. 2019 kl. 21:15 skrev Adam Walz <[hidden email]>:

It looks like solr 7.7.x is currently designated as the LTS version on the website. https://lucene.apache.org/solr/downloads.html

On Wed, Nov 13, 2019 at 11:36 AM Erick Erickson <[hidden email]> wrote:
I have zero interest in having an LTS “policy” that requires any further commitment of my personal time to random people who ask for it but aren’t willing to pay. I consider my non-paid work to Solr a _volunteer_ activity, not something anyone has a right to demand as “support”, long-term or otherwise.

Best,
Erick

> On Nov 13, 2019, at 12:34 PM, Shawn Heisey <[hidden email]> wrote:
>
> We've had somebody on the Solr mailing list asking questions about our LTS version.
>
> The thing about this is that we don't really HAVE an LTS version.  Our major version release pace and the way we deal with older branches mean that a single major version branch is never in a given state for long enough to really qualify as "long term".
>
> The 7.x branch is in maintenance mode, so most problems that people encounter with it will only be addressed in a future 8.x version.  In my mind, that means it doesn't qualify as LTS.  The current stable branch is always getting new features, which I think disqualifies that branch for the LTS label.
>
> The tomcat project has an interesting way of determining when support ends.  Here's a message outlining it:
>
> https://markmail.org/message/6wycxatwzwycmf43
>
> My question is:  Do we want to change what we do here, or are we happy with the current model?  If we did change it, I'm not completely sure what that would look like.
>
> Thanks,
> Shawn
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: [hidden email]
> For additional commands, e-mail: [hidden email]
>


---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]



--
Adam Walz

Reply | Threaded
Open this post in threaded view
|

Re: Do we want to pursue an LTS designation?

Chris Hostetter-3

: The term LTS is used loosely and we actually do not promise anything. What we say is
:
: > 7.7.x Version in the previous major release for bugfixes only (LTS)
        ...

: Being the one coining the LTS phrasing I am not opposed to changing it
: to something else. But through the years we have used that term I have
: not seen a lot of such requests.

I didn't realize you had put that up on the site -- it does seem very
missleading to me as the "LT" in "LTS" is suppose to mean "Long Term" but
we do not -- in practice or intent -- have any plans as a project to
support "7.7.x" in particular any longer then we would any other arbitrary
"latest" minor release.

Nor did we ever give users who initially installed 7.7.0 when it came out
any reason to think it would be "supported" (and get bug fixes) for a
"longer term" then a hypothetical 7.8.0 that might have come out a day
after they installed some 7.7.x, and replace it's row on that page that
you've labeled "LTS".

We may not have ever gotten questions about it, but that may just be
because people have very specific assumptions about what it means, and
never thought to ask questions to verify those assumptions.

I think, given how the project *actually* supports releases, I think we
should remove references to "LTS" from that page, and leave the other
description "Version in the previous major release for bugfixes only" as
it stands -- or perhaps tighten it up even more: "Version in the previous
major release that may get bug fixs"


-Hoss
http://www.lucidworks.com/

---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: Do we want to pursue an LTS designation?

Andrzej Białecki-2
I agree with the removal of LTS designation - there’s no formal commitment from the community to support this or that release for that long.

Even though in practice bug fixes are often backported to older branches that are still widely used, there’s no actual contract to do so, and implying there is one is misleading.

> On 13 Nov 2019, at 22:46, Chris Hostetter <[hidden email]> wrote:
>
>
> : The term LTS is used loosely and we actually do not promise anything. What we say is
> :
> : > 7.7.x Version in the previous major release for bugfixes only (LTS)
> ...
>
> : Being the one coining the LTS phrasing I am not opposed to changing it
> : to something else. But through the years we have used that term I have
> : not seen a lot of such requests.
>
> I didn't realize you had put that up on the site -- it does seem very
> missleading to me as the "LT" in "LTS" is suppose to mean "Long Term" but
> we do not -- in practice or intent -- have any plans as a project to
> support "7.7.x" in particular any longer then we would any other arbitrary
> "latest" minor release.
>
> Nor did we ever give users who initially installed 7.7.0 when it came out
> any reason to think it would be "supported" (and get bug fixes) for a
> "longer term" then a hypothetical 7.8.0 that might have come out a day
> after they installed some 7.7.x, and replace it's row on that page that
> you've labeled "LTS".
>
> We may not have ever gotten questions about it, but that may just be
> because people have very specific assumptions about what it means, and
> never thought to ask questions to verify those assumptions.
>
> I think, given how the project *actually* supports releases, I think we
> should remove references to "LTS" from that page, and leave the other
> description "Version in the previous major release for bugfixes only" as
> it stands -- or perhaps tighten it up even more: "Version in the previous
> major release that may get bug fixs"
>
>
> -Hoss
> http://www.lucidworks.com/
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: [hidden email]
> For additional commands, e-mail: [hidden email]
>


---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: Do we want to pursue an LTS designation?

Bram Van Dam
In reply to this post by Erick Erickson
On 13/11/2019 20:36, Erick Erickson wrote:
> I have zero interest in having an LTS “policy” that requires any further commitment of my personal time to random people who ask for it but aren’t willing to pay. I consider my non-paid work to Solr a _volunteer_ activity, not something anyone has a right to demand as “support”, long-term or otherwise.

I hope no one is expecting you to put in free support hours based on
some random LTS designation. And if you're ever in my neck of the woods,
I'll gladly buy you a couple of beers to thank you for the effort you do
put in.

It *is* really annoying that there is no better upgrade path than
"reindex everything and hope for the best". Making it easier to perform
in place upgrades would probably go a long way in making users happier,
and would certainly reduce the calls for an LTS version.

I had some time off this week and I spent it poking around at the
possibility of making index upgrades easier, but I'm afraid I didn't get
anywhere with it. Too much low level Lucene stuff is involved that I'm
not familiar with (yet).

 - Bram

---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: Do we want to pursue an LTS designation?

Jörn Franke
Well sometimes even reindexing might not always be avoidable when upgrading. However, there should be a more user friendly way. Not every Solr deployment that one might inherit has foreseen this. Eg in case Solr is used as a NoSQL database where the application puts data in Solr, but not outside Solr for the case of reindexing. In those case it would be useful that Solr can (configurable) write the original SolrInputDocument somewhere and this original document can then be user for reindexing in case of major updates.

> Am 15.11.2019 um 18:50 schrieb Bram Van Dam <[hidden email]>:
>
> On 13/11/2019 20:36, Erick Erickson wrote:
>> I have zero interest in having an LTS “policy” that requires any further commitment of my personal time to random people who ask for it but aren’t willing to pay. I consider my non-paid work to Solr a _volunteer_ activity, not something anyone has a right to demand as “support”, long-term or otherwise.
>
> I hope no one is expecting you to put in free support hours based on
> some random LTS designation. And if you're ever in my neck of the woods,
> I'll gladly buy you a couple of beers to thank you for the effort you do
> put in.
>
> It *is* really annoying that there is no better upgrade path than
> "reindex everything and hope for the best". Making it easier to perform
> in place upgrades would probably go a long way in making users happier,
> and would certainly reduce the calls for an LTS version.
>
> I had some time off this week and I spent it poking around at the
> possibility of making index upgrades easier, but I'm afraid I didn't get
> anywhere with it. Too much low level Lucene stuff is involved that I'm
> not familiar with (yet).
>
> - Bram
> B‹KKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKCB•È[œÝXœØÜšX™KK[XZ[ˆ]‹][œÝXœØÜšX™PXÙ[™K˜\XÚK›Ü™ÃB‘›ÜˆY][Û˜[ÛÛ[X[™ËK[XZ[ˆ]‹Z[XÙ[™K˜\XÚK›Ü™ÃBƒB

---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: Do we want to pursue an LTS designation?

Jörn Franke
In reply to this post by Bram Van Dam
Well sometimes even reindexing might not always be avoidable when upgrading. However, there should be a more user friendly way. Not every Solr deployment that one might inherit has foreseen this. Eg in case Solr is used as a NoSQL database where the application puts data in Solr, but not outside Solr for the case of reindexing. In those case it would be useful that Solr can (configurable) write the original SolrInputDocument somewhere and this original document can then be user for reindexing in case of major updates.


> Am 15.11.2019 um 18:50 schrieb Bram Van Dam <[hidden email]>:
>
> On 13/11/2019 20:36, Erick Erickson wrote:
>> I have zero interest in having an LTS “policy” that requires any further commitment of my personal time to random people who ask for it but aren’t willing to pay. I consider my non-paid work to Solr a _volunteer_ activity, not something anyone has a right to demand as “support”, long-term or otherwise.
>
> I hope no one is expecting you to put in free support hours based on
> some random LTS designation. And if you're ever in my neck of the woods,
> I'll gladly buy you a couple of beers to thank you for the effort you do
> put in.
>
> It *is* really annoying that there is no better upgrade path than
> "reindex everything and hope for the best". Making it easier to perform
> in place upgrades would probably go a long way in making users happier,
> and would certainly reduce the calls for an LTS version.
>
> I had some time off this week and I spent it poking around at the
> possibility of making index upgrades easier, but I'm afraid I didn't get
> anywhere with it. Too much low level Lucene stuff is involved that I'm
> not familiar with (yet).
>
> - Bram
> B‹KKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKCB•È[œÝXœØÜšX™KK[XZ[ˆ]‹][œÝXœØÜšX™PXÙ[™K˜\XÚK›Ü™ÃB‘›ÜˆY][Û˜[ÛÛ[X[™ËK[XZ[ˆ]‹Z[XÙ[™K˜\XÚK›Ü™ÃBƒB

---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: Do we want to pursue an LTS designation?

Bram Van Dam
In reply to this post by Jörn Franke
On 15/11/2019 19:14, Jörn Franke wrote:
> Well sometimes even reindexing might not always be avoidable when upgrading. However, there should be a more user friendly way. Not every Solr deployment that one might inherit has foreseen this. Eg in case Solr is used as a NoSQL database where the application puts data in Solr, but not outside Solr for the case of reindexing. In those case it would be useful that Solr can (configurable) write the original SolrInputDocument somewhere and this original document can then be user for reindexing in case of major updates.

Writing the SolrInputDocument to disk would get really expensive really
quickly.

When all fields are stored it's relatively easy to build a new index
from an old one. But when you have a any non-stored fields, things
become a bit less convenient. In some cases you can uninvert the field
and recreate the content based on the terms used. Still tricky.

A way to perform in-place updates in Lucene would help in this case. But
that seems hard to implement, and it would only help with this
particular upgrade problem.

When I have more time I'll keep hacking away on an upgrade tool that
works for our use-case. If it turns out to be usable for anyone else,
I'll give it back to the community.

Also; not sure why the MS mail servers are messing up some of my mails.
Apologies.

 - Bram

---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: Do we want to pursue an LTS designation?

Erick Erickson
Bram:

Andrzej Bailecki and I worked on something similar, it might be good to compare notes. I gave a talk last Activate that might be useful for you to look at for ideas.

Basically there are several issues we worked out:
1> how to insure that all segments were rewritten
2> If the schema is changing, how to update the collections one at a time even with shared configsets
3> the nuts-and-bolts of the rewriting.

https://www.youtube.com/watch?v=eaQBH_H3d3g

Best,
Erick

> On Nov 15, 2019, at 2:15 PM, Bram Van Dam <[hidden email]> wrote:
>
> On 15/11/2019 19:14, Jörn Franke wrote:
>> Well sometimes even reindexing might not always be avoidable when upgrading. However, there should be a more user friendly way. Not every Solr deployment that one might inherit has foreseen this. Eg in case Solr is used as a NoSQL database where the application puts data in Solr, but not outside Solr for the case of reindexing. In those case it would be useful that Solr can (configurable) write the original SolrInputDocument somewhere and this original document can then be user for reindexing in case of major updates.
>
> Writing the SolrInputDocument to disk would get really expensive really
> quickly.
>
> When all fields are stored it's relatively easy to build a new index
> from an old one. But when you have a any non-stored fields, things
> become a bit less convenient. In some cases you can uninvert the field
> and recreate the content based on the terms used. Still tricky.
>
> A way to perform in-place updates in Lucene would help in this case. But
> that seems hard to implement, and it would only help with this
> particular upgrade problem.
>
> When I have more time I'll keep hacking away on an upgrade tool that
> works for our use-case. If it turns out to be usable for anyone else,
> I'll give it back to the community.
>
> Also; not sure why the MS mail servers are messing up some of my mails.
> Apologies.
>
> - Bram
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: [hidden email]
> For additional commands, e-mail: [hidden email]
>


---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: Do we want to pursue an LTS designation?

Bram Van Dam
On 15/11/2019 23:07, Erick Erickson wrote:
> Andrzej Bailecki and I worked on something similar, it might be good to compare notes. I gave a talk last Activate that might be useful for you to look at for ideas.
> https://www.youtube.com/watch?v=eaQBH_H3d3g

Thanks, that sounds super useful! I'll look into it.

 - Bram

---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: Do we want to pursue an LTS designation?

Jan Høydahl / Cominvent
I just removed LTS wording from the Solr download page.

--
Jan Høydahl, search solution architect
Cominvent AS - www.cominvent.com

18. nov. 2019 kl. 09:22 skrev Bram Van Dam <[hidden email]>:

On 15/11/2019 23:07, Erick Erickson wrote:
Andrzej Bailecki and I worked on something similar, it might be good to compare notes. I gave a talk last Activate that might be useful for you to look at for ideas.
https://www.youtube.com/watch?v=eaQBH_H3d3g

Thanks, that sounds super useful! I'll look into it.

- Bram

---------------------------------------------------------------------
To unsubscribe, [hidden email]
For additional commands, [hidden email]