On Sun, Jan 10, 2016 at 10:27 PM, Rene Moser <[email protected]> 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. -- Erik
