Announcement

Collapse
No announcement yet.

A Proposal To Update Ubuntu's Kernel/Mesa/GNOME Components On A Monthly Basis

Collapse
X
 
  • Filter
  • Time
  • Show
Clear All
new posts

  • theghost
    replied
    Originally posted by tjaalton View Post

    Artful-proposed (and xenial-proposed!) has had mesa-17.2.4 since November 22nd, but getting real people to actually verify the bugs it should fix is hard and time consuming. Since the paperwork takes ages, I don't even try to chase after every point release, so the unwritten "policy" regarding Mesa is that the last point release will be SRU'd. In this case I couldn't wait that long, and because 17.3.0 was delayed it means that 17.2.x is still not closed yet (AIUI). Besides, point releases can still regress something.

    Regarding that intel-spi thing; the upstream patch(es?) that eventually got backported was/were not marked for stable, so how on earth would that've been caught at the time?
    Well, thanks for the honest explanation. I know that resources are limited, especially on the Desktop and on the non-LTS-releases.
    Maybe we can hope in future for more automated minor releases with zero paperwork. The buildsystem can build it, release it to proposed and when no bugs appear, automatically bring it on. People who don't respond to bug reports have to revalidate their bug against the new version.

    Luckily I am not in the situation where I don't have to recompile Mesa for every minor version but in the past that was the case for my Sandybridge on Ubuntu.
    That drove me away from Ubuntu. Because I had no use for a broken stable version.

    Leave a comment:


  • tjaalton
    replied
    Originally posted by pq1930562 View Post

    I still fail to understand why there is linux-generic-hwe-16.04 and linux-generic-hwe-16.04-edge but only xserver-xorg-hwe-16.04 and no server-xorg-hwe-16.04-edge.
    Because it's not just the xserver but drivers too. So you'd need dozens of -edge packages of the drivers, including nvidia (but most likely no support for AMDGPU-Pro). Not going to happen.

    Leave a comment:


  • pq1930562
    replied
    Originally posted by tjaalton View Post

    This was already discussed to death back then. I won't repeat it all here.

    The xserver (stack, including drivers) backport is not like the kernel, which is a fairly straightforward backport of N+1 kernel.
    I still fail to understand why there is linux-generic-hwe-16.04 and linux-generic-hwe-16.04-edge but only xserver-xorg-hwe-16.04 and no server-xorg-hwe-16.04-edge.

    Originally posted by slacka View Post
    As someone who ran Arch on several machines for several years, every troublesome upgrade was a kernel bug or a driver bug. Some can be very serious, for example the kernel upgrade that bricked the BIOS on some Lenovo laptops. For my use case, I think the kernel and drivers should be the most well tested and slowest to upgrade. For kernel and drivers, the hardware enablement (HWE) is as aggressive as I'd ever want to see in Ubuntu.
    You just failed to name a specific example where Arch brought you some trouble with kernel and driver upgrades. Instead, you named an issue that happened on Ubuntu, which even occured because of an experimental/unfinished option being enabled (i.e. should not have been enabled in the first place).

    Originally posted by slacka View Post
    What I would like to see upgraded more frequently are the applications. When applications have bugs, it's trivial to downgrade and much less problematic. For my use case, I miss the Arch model for applications. For exmple, recently I went to download a youtube stream, only to find out that the youtube-dl was over a year out of date and didn't work anymore. Another example of an app that I needed to switch to a ppa was LibreOffice to fix a bug in the outdated version shipped with LTS.
    This +1000. It's absolutely ridiculous how outdated some apps are on Ubuntu (and several other Linux distros).

    That being said: Now that Canonical has introduced Snap, the actual app developers/package maintainers are to be blame. If app developers would package, distribute and update their apps using Snap packages directly from upstream, that issue would be non-existent.

    So no excuse for app developers. All this fragmented packaging needs to stop and everything should be delivered via Snap packages. Problem solved (just like on MS Windows).

    That being said:

    Originally posted by slacka View Post
    Another example of an app that I needed to switch to a ppa was LibreOffice to fix a bug in the outdated version shipped with LTS.
    Use the Snap package:



    Last edited by pq1930562; 31 December 2017, 09:52 PM.

    Leave a comment:


  • slacka
    replied
    As someone who ran Arch on several machines for several years, every troublesome upgrade was a kernel bug or a driver bug. Some can be very serious, for example the kernel upgrade that bricked the BIOS on some Lenovo laptops. For my use case, I think the kernel and drivers should be the most well tested and slowest to upgrade. For kernel and drivers, the hardware enablement (HWE) is as aggressive as I'd ever want to see in Ubuntu.

    What I would like to see upgraded more frequently are the applications. When applications have bugs, it's trivial to downgrade and much less problematic. For my use case, I miss the Arch model for applications. For exmple, recently I went to download a youtube stream, only to find out that the youtube-dl was over a year out of date and didn't work anymore. Another example of an app that I needed to switch to a ppa was LibreOffice to fix a bug in the outdated version shipped with LTS.

    Leave a comment:


  • tjaalton
    replied
    Originally posted by pq1930562 View Post

    Still disappointed that you tjaalton refused to add a xserver-xorg-hwe-16.04-edge package to Ubuntu:

    https://lists.ubuntu.com/archives/ub...-May/date.html

    This was already discussed to death back then. I won't repeat it all here.

    The xserver (stack, including drivers) backport is not like the kernel, which is a fairly straightforward backport of N+1 kernel.

    Leave a comment:


  • pq1930562
    replied
    Originally posted by tjaalton View Post
    Artful-proposed (and xenial-proposed!) has had mesa-17.2.4 since November 22nd, but getting real people to actually verify the bugs it should fix is hard and time consuming. Since the paperwork takes ages, I don't even try to chase after every point release, so the unwritten "policy" regarding Mesa is that the last point release will be SRU'd. In this case I couldn't wait that long, and because 17.3.0 was delayed it means that 17.2.x is still not closed yet (AIUI). Besides, point releases can still regress something.
    Still disappointed that you tjaalton refused to add a xserver-xorg-hwe-16.04-edge package to Ubuntu:

    https://lists.ubuntu.com/archives/ub...-May/date.html

    Leave a comment:


  • tjaalton
    replied
    Originally posted by theghost View Post

    The greatest problem is that Ubuntu creates a snapshot of kernel and userspace at a certain date and takes this as base for the next release.
    But even though minor bugfix updates are released within the window of snapshot date and release date of the snapshot, they are not contained within the release.
    Same goes for updates after release date.
    Here are some examples for Ubuntu's latest release (17.10):

    - Kernel version today is 4.13.0-16 (whatever this strange version system is, I guess and hope it's 4.13.16) --> Upstream: EOL (not maintained anymore by upstream) --> so bad choice of kernel version for a release

    - Mesa 17.2.2 is in 17.10 --> Upstream: 17.2.8 (!) so Ubuntu missed 6 (!) releases of bugfixes for graphics.

    You can complete the list on your own.

    We even have a great use-case why this policy is bad. Ubuntu uses an outdated Kernel, forgot to backport important patches for intel-spi and activated a kernel module despite the warning, with the result that a lot of notebooks were bricked.
    Artful-proposed (and xenial-proposed!) has had mesa-17.2.4 since November 22nd, but getting real people to actually verify the bugs it should fix is hard and time consuming. Since the paperwork takes ages, I don't even try to chase after every point release, so the unwritten "policy" regarding Mesa is that the last point release will be SRU'd. In this case I couldn't wait that long, and because 17.3.0 was delayed it means that 17.2.x is still not closed yet (AIUI). Besides, point releases can still regress something.

    Regarding that intel-spi thing; the upstream patch(es?) that eventually got backported was/were not marked for stable, so how on earth would that've been caught at the time?

    Leave a comment:


  • pq1930562
    replied
    Originally posted by starshipeleven View Post
    I was NOT talking about blocking windows updates

    Yes you did. Feature updates (i.e. upgrade from Windows 10 1607 to 1703 to 1709 and so on...) are being delivered via Windows Update.

    And the screenshot that I presented to you shows you how to defer these feature updates, which gives you time to wait until device manufacturers have come up with new drivers.

    Deferring feature upgrades does not defer security updates. So you could still be on Windows 10 1607 today and receive security updates (even though 1709 is the current version).

    Originally posted by starshipeleven View Post
    If you knew how to read [...] and would stop posting bullshit.
    So cute .

    Leave a comment:


  • starshipeleven
    replied
    Originally posted by pq1930562 View Post
    If you would know how to google, then you would know about the following settings and stop whining:

    https://filedb.experts-exchange.com/...settings-2.png
    If you knew how to read, then you would know that I was NOT talking about blocking windows updates (as easy as setting the internet connection as "metered" https://www.howtogeek.com/226722/HOW...ON-WINDOWS-10/ and worked 100% from day 1, while your method was added much later) and would stop posting bullshit.

    I personally use http://www.thewindowsclub.com/make-w...indows-updates because I like to have the old settings back, and I have Windows 10 Pro anyway (does not work on Home versions)

    I'd also like to point out that blocking updates works perfectly fine also on Linux.

    But blocking updates is not a good idea in general.

    Leave a comment:


  • kaprikawn
    replied
    Originally posted by DrYak View Post

    Yet another possible solution : try experimenting with openSuSE Tumbleweed.
    I installed SuSe a long time ago for about five minutes, didn't like it and installed something else. I think it's about time I gave it another shot. I might stick it on my test box and give it a whirl. Thanks for the input.

    Leave a comment:

Working...
X