There are good points for and against LTS. I do have specific use case that LTS solves, but in my opinion the scope of LTS would need to be revised.
Why LTS is good idea? If you have environment with thousands of servers, upgrading from 4.5 to 4.7 and beyond would be rather risky. There are instances when specific issues will surface only on very large scale. I've seen it many times, where my small QA environments would work just fine, but once i go into a much larger environment with at least 300+ hypervisors - things dont work as well. Moreover, it may take some time for these issues to surface. LTS buys us time to properly test, plan, migrate and yet be up-to-date. If we are open to revising the scope of LTS, it may be more manageable. Things to consider with LTS to include include: 1) Applicable bug and security fixes 2) Low impact features that don't have dependencies on newer code (i.e. strongswan VPN would *not* qualify) 3) Features that don't require DB schema change (if such comes thru, it needs to be heavily scrutinized and commiter needs to provide and test the upgrade path to next release) If i'm not mistaken, kernel and most of linux open source packages are similarly maintained (though in many cases by distribution vendors like redhat/debian). Regards ilya On 1/10/16 2:46 PM, Erik Weber wrote: > On Sun, Jan 10, 2016 at 10:27 PM, Rene Moser <m...@renemoser.net> wrote: > >> >> On 01/10/2016 10:07 PM, Wido den Hollander wrote: >>> Ok, understood. However, it will be up to users on their own to pick >>> this LTS maintainment up. >> >> It would be up to the devs making fixes small (so no squashing for >> fixes) and notify the one maintaining the LTS version if they feel the >> fix is that important to be in LTS. Wouldn't be that hard work. >> >> > What if the fix is part of a refactorization or a new feature? > Providing a LTS is not 'easy as pie' with a product like CloudStack where a > lot of code changes over time. > > For instance, /if/ the strongswan feature is merged to 4.8, how to you > handle /ANY/ VPN fixes in 4.5 since they don't even use the same software? > And the whole VR process was refactored in 4.6 -- meaning you won't be > using the same scripts, or even the same language. > > Even if a bugfix is included in master and tested, it is impossible to say > how it will react with an older/different solution. > > The same can be said for library updates etc. > > Don't get me wrong, I'm not opposing a LTS version -- actually I would > rather like to have one. I just want to be clear about the fact that it > won't be always be easy, and not all fixes might be possible to backport -- > depending on how strict you'll be with 3rd party stuff. > > > >>> That means testing, releasing, testing, backporting, testing, releasing. >>> >>> Certain users will focus on getting new releases out and others on doing >>> LTS work. >> >> The process of backporting is not defined yet, but I would like to adopt >> the Linux kernel long term policy: >> >> * Fix must be already in mainline >> > > See above, the fix might not be necessary in master/mainline. > > >> * Fix must be important. >> > > Who defines what 'important' is? > > >> * Fix must be obvious and small. >> >> Which means, we only fix stuff in LTS which is already fixed in >> mainline. Important stuff only. >> >> We can even define, the mainline version must be released with the fix, >> before getting into LTS. So even the LTS releases would be behind the >> mainline releases and the fix has been tested in mainline. >> > > On a last note, doing LTS -- atleast in my opinion -- requires commitment. > Anything called LTS is usually getting a lot of user focus/traction and > have to be rock solid and maintained. >
