[arch-general] Tobias Powalowski and his nonsensical maintenance decisions

[Carsten Mattner]

On Fri, Apr 28, 2017 at 6:43 PM, Eric Blau <eblau at eblau.com> wrote:
> On Fri, Apr 28, 2017 at 2:19 PM, Carsten Mattner
> <carstenmattner at gmail.com> wrote:
>> On Fri, Apr 28, 2017 at 5:11 PM, Eric Blau <eblau at eblau.com> wrote:
>>> On Fri, Apr 28, 2017 at 12:29 PM, Carsten Mattner via arch-general
>>> <arch-general at archlinux.org> wrote:
>>>
>>> There's a fix that's been submitted to the tip, but no effort has
>>> been made to patch the bug in the 4.10.x stable series. It seems the
>>> devs don't care about having a stable kernel to use, only about
>>> moving forward the tip and staying on the bleeding edge. Shouldn't
>>> at least showstopper kernel panics be patched to the "stable"
>>> release?
>>>
>>> I requested a fix on the tip to be patched in the 4.9.x stable
>>> series a couple months ago because I tested the fix myself and
>>> verified it "worked for me" but it was subsequently reverted. I'm
>>> sure I don't know enough about the i915 driver to be able to make
>>> these types of decisions about what should or should not be patched
>>> other than to help with testing, but it would be nice if the i915
>>> dev team made an effort to propagate fixes to stable as well.
>>
>> It's possible that the fix causes other issues, but I've also seen
>> crash fixes take very long until landing in a stable release,
>> sometimes taking 2 or 3 releases, while refactorings are intertwined
>> with other fixes in stable releases. It looks odd.
>
> Yes, agreed here. The fix I requested to be patched to 4.9.x when it
> was the stable release back in the Feb/March timeframe was from
> September 2016 but still hadn't made it into a stable release 5 or 6
> months later.

Wouldn't it be nice if all projects would communicate that a bug
is low priority and may not be fixed anytime soon unless you get
involved with a diff, although that's no guarantee it will be merged.

Some projects have bugs that affect only few users or are hard to fix
and are sitting in OPEN for a decade, but it's common that request
for status info is usually ignored. Other projects just close bugs
after a timeout, implying that it must be irrelevant now.

>> I wonder how the situation is with AMD and nVidia GPUs with open and
>> closed driver stacks.
>
> I don't have these problems with a NVIDIA GeForce GTX 970 on my
> desktop machine.

No tearing, nothing, without a need for special hacks/configs in X?
nVidia binary drivers?

>> It seems that if you run GNOME3 with GTK3 under Wayland and only GTK3
>> apps with GDK_BACKEND=wayland and no X app, then it works well, but
>> that's like forcing everyone to use just Android apps under ChromeOS.
>>
>> With libweston and libweston-desktop and further fixes in Xwayland,
>> maybe 2018 we will finally have what Wayland promised very long ago. I
>> wouldn't blame outsiders if they looked at Linux Desktop and thought
>> that there's too many variants and too much change with little
>> stabilization going on.
>
> A big reason why Linux Desktop seems like a lost cause.

Politically it's hard to rectify since there are camps with
NIHism and recurring wheel reinventing without a stable API/ABI
path in many modules.

A Windows application written for Windows 2000 still works the
same, unless it used some borderline stuff, under Windows 10.

Qt is less affected by this since they have real world embedded
customers and cannot mess around that much like GTK3 with their
GNOME3 is the environment supported policy.

>> Then there's outstandingly stable software like GNU Emacs, FVWM, xterm
>> or XMonad. Your config from a decade or two ago still works and with
>> minimal to none deprecation disruption.
>
> I prefer stable software that lets me get my job done like i3, vim,
> etc. I rarely have problems running the latest versions included in
> Arch. The kernel is another story altogether. I frequently have to
> switch between linux and linux-lts or build my own kernel with various
> patches in order for my machines to run stable.

Exactly. I also prefer to have config files that work across generations
of a program and can be customized, transferred around. It's frightening
to see the reinventions and changes in KDE and GNOME config paths and
storage engines. To set GTK3's theme and font settings, you need to provide
it in settings.ini plus dconf binary db or else it will display correctly
either in X11 mode or Wayland mode. Under Wayland GTK3 zooms the widgets
instead of scaling them, which gives you blurred/washed-out windows.
GTK3 is like Windows 10. It fixed core issues for Wayland support, but
broke much functionality on the way.

>> So when it comes to open source video driver stacks, the best stragey
>> is running one of the last two generations of GPU (Broadwell and
>> Skylake) and always stay in thet range since older GPUs lose QA
>> coverage with new GPUs coming out. If the capabilities of a GPU are
>> clear and you cannot expect to have newer OpenGL support in a newer
>> Mesa, then it would make sense to have a stable but old i915 stack for
>> old GPUs that doesn't change vs new i915 stack for newer GPUs, but
>> Linux is a monolithic design without driver ABIs for good reasons that
>> show their disadvantage when QA is insufficient.
>
> My 2015 Broadwell-based MacBook Pro is not that old, yet I have i915
> issues with it almost kernel release.

That sounds scary. Though I'm relieved to hear it's not just older
GPUs which go ignored or something like that.