<div dir="ltr"><div class="gmail_extra"><div class="gmail_quote">On Wed, Jul 26, 2017 at 7:50 PM, Bob Friesenhahn <span dir="ltr"><<a href="mailto:bfriesen@simple.dallas.tx.us" target="_blank">bfriesen@simple.dallas.tx.us</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><span class="">On Wed, 26 Jul 2017, Tobias Oetiker wrote:<br>
<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
we have discussed this in the core team and found that no one of us has been<br>
using LTS until now and no one is planning to do so in the future ...<br>
</blockquote></span></blockquote><div><br></div><div>A couple of points here:<br><br></div><div>The first is that while the project is finding its feet, making decisions about<br></div><div>what the detailed support model might look like in 6 months to 2 years time<br></div><div>is somewhat premature.<br><br></div><div>The second is that the support model doesn't have to be an exact mirror<br></div><div>of the schedule that OmniTI put in place. There's no reason you couldn't<br></div><div>adjust the cadence and level of releases.<br><br></div><div>Now the current release (151022) is marked as LTS. So at least you're in<br></div><div>a reasonably stable place right now and have options, with no need to<br></div><div>commit to anythjing for a few months.<br><br></div><div>Which does open the question: how many people need LTS? (And what<br></div><div>does LTS mean for them - in terms of how long support would be needed,<br></div><div>and what level of support/backports they expect.) Perhaps Chris could<br></div><div>chip in here, but I know that with my $DAYJOB hat on the idea of<br></div><div>dropping security updates for release X as soon as release Y comes out<br></div><div>is a bit of a non-starter.<br></div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><span class="">
</span>
This would be a great way for a commercial outfit which offers paid support contracts to get involved.  LTS releases are quite a lot of commitment and work but a commercial support company might be able to commit to doing this work.<br></blockquote><div><br></div><div>I think we've already concluded that doing this isn't a viable commercial<br></div><div>proposition.<br></div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
Alternatively, a different set of volunteers could focus on LTS.<span class="HOEnZb"><font color="#888888"></font></span><br clear="all"></blockquote></div><br></div><div class="gmail_extra">Well quite - community projects tend to have their direction set by those<br></div><div class="gmail_extra">actually doing the work. Doing LTS "properly" is a heck of a lot of work<br></div><div class="gmail_extra">(and the amount of work increases rapidly over time as you diverge from<br></div><div class="gmail_extra">mainstream). But I can imagine an LTS-lite extended support model<br></div><div class="gmail_extra">with just crucial security fixes would be a lot easier (and might be what<br></div><div class="gmail_extra">customers want anyway).<br></div><div class="gmail_extra"><br>-- <br><div class="gmail_signature" data-smartmail="gmail_signature">-Peter Tribble<br><a href="http://www.petertribble.co.uk/" target="_blank">http://www.petertribble.co.uk/</a> - <a href="http://ptribble.blogspot.com/" target="_blank">http://ptribble.blogspot.com/</a></div>
</div></div>