Can we include HWE in the release version?
John Johansen
john.johansen at canonical.com
Wed Apr 6 21:52:16 UTC 2016
On 04/06/2016 02:32 PM, Dimitri John Ledkov wrote:
> On 6 April 2016 at 22:25, Xen <list at xenhideout.nl> wrote:
>> Bryan Quigley schreef op 06-04-16 22:35:
>>> Hi all,
>>>
>>> The naming scheme of just "Ubuntu 14.04.4 LTS" is no longer
>>> meaningful when it comes to determining what kernel/mesa/xorg you are
>>> on. It's also confusing to many users what 14.04.4 actually means
>>> and it makes determining if you are supported more difficult [1].
>>>
>>> I propose for 16.04 we change it so that the HWE# is included in the
>>> version, so it's trivial to determine the support level.
>>>
>>> So for example, if we had done this for 14.04 we would have releases like:
>>> Ubuntu 14.04.4 LTS - Everyone up-to-date with stock kernel
>>> Ubuntu 14.04.3 LTS HWE15.04 - Out of date with vivid kernel
>>> Ubuntu 14.04.4 LTS HWE15.04 - Up-to-date with vivid kernel
>>
>> Personally I feel that naming scheme is hideous and will confuse even
>> more people.
>>
>> What does HWE even mean? I can look it up, but it is not like it is some
>> kind of well known acronym or abbreviation.
>>
>> (The way I understood it these point releases indeed brought new kernels
>> in addition to something else. The confusion that I experienced was more
>> the weird focus on end-of-support dates that was different for every
>> point release, creating tiers of support that utterly confused me,
>> particularly because the context with other (newer) versions of the
>> distribution was not clear. The idea of point releases bringing new
>> kernels and that "HWE" is not confusing at all. However, if this
>> dramatically is going to change "end of support" dates, then suddenly it
>> is not comprehensible anymore --- did it mean that a getting point
>> release meant less support?
>>
>> What I remember is that the point releases had less support, which is
>> not understandable because they are newer systems.
>>
>> Also if a point release actually means newer versions of all software
>> this is confusing by itself. Creating the ability for new hardware is
>> easy to understand. But if repos for .3 and .4 are going to be entirely
>> different, and now you are going to create 2 dimensions: currency of
>> software, and currency of kernel/HWE and you can mix them at will: that
>> is not helpful.
>>
>> So I would suggest the confusion did not come from the naming scheme.
>> The confusion came from the fact that these varying levels of support
>> were incomprehensible. If anything upgrading to a newer kernel should be
>> recommended and encouraged for the largest part and if anything that
>> should give the benefit of longer support -- since you are up to date
>> now, right?
>>
>> The fact that 14.04.1 is listed at end of life april 2019 and 14.04.2 is
>> listed at august 2016 is just utterly confusing. Changing the naming is
>> not going to help that.
>>
>> If these two components have different EOL you can just say so, I'm not
>> sure if that is the case.
>>
>> So if you wanted some thoughts, my thought is that your proposal here
>> would increase the confusion while not tackling the real issue.
>>
>> Regards.
>>
>
> LTS has 5 years of support.
>
> There are multiple kernels available with full 5 year support:
> - original (from .0 original release & .1 release)
> - next-lts (from a .5 point release)
>
> Intermediate releases backports:
> - Available in .2; .3; .4
> - Supported until .5 release which comes with next-LTS kernel
> - Upgrade path is to the next LTS release, or to the .5 HWE stack
>
> We do send EOL announcements for the HWE kernels. I do not believe we
> automatically upgrade people from them to the .5 / next-LTS kernel,
> maybe we should. (or i am wrong, and we totally do it).
> However in practice, people who use/care about HWE kernels upgrade to
> the next HWE stack and/or next LTS release quite rapidly.
>
For those who opt-in sure, but there are people who buy machines with
a point release installed. I don't think we can make that assumption
for them.
More information about the Ubuntu-devel-discuss
mailing list