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

fnodeuser

28 Apr 2017 28 Apr '17

2:40 p.m.

Tobias Powalowski, you continue to place pkgs in the testing repo that do not require any further testing. for what reasons, exactly, do the linux 4.10.13 and hwids 20170328 pkgs need to be in testing for 4+ days? also, you did not replace git:// with git+https:// in the hwids PKGBUILD file. github has HTTPS enabled for everything.

Show replies by thread

Florian Pritz

28 Apr 28 Apr

3:21 p.m.

On 28.04.2017 14:40, fnodeuser wrote:

...

you continue to place pkgs in the testing repo that do not require any further testing.

Thank you for showing that you do not understand our repository policy. All [core] packages go to [testing] first to ensure that we do not completely break anyone's system. This has happened before and funnily enough it happened with a kernel that did not boot for anyone. Because of this [testing] has been created. You really managed to come up with the best example here.

...

for what reasons, exactly, do the linux 4.10.13 and hwids 20170328 pkgs need to be in testing for 4+ days?

I am not sure on which planet you live and how many hours a day has for you, but on Earth those packages have been in testing for roughly 7 hours (2017-04-28 07:57 UTC and 2017-04-28 08:17 UTC). As for the reasoning, see above.

...

also, you did not replace git:// with git+https:// in the hwids PKGBUILD file. github has HTTPS enabled for everything.

While this specific suggestion is correct, the way it has been presented here and in the past is not. Context matters, and if you annoy people they will stop listening to you. I have put you on moderation. If you continue annoying us like this there will be further consequences. Consider this your final warning. There will not be another. Florian

Genes Lists

3:41 p.m.

1) Tobias: Thank you for doing a terrific and diligent job packaging and testing kernels and, which come into testing in short order. 2) Florian: Thank you for your comments - agree completely. 3) Adding to what Florian said - Testing also allows Arch users to signoff after performing their own testing which strengthens the program by adding broader testing across different systems. -- Gene lists@sapience.com

Martin Kühne

5:13 p.m.

Today is the 28th, and the date reported by pacman is the 27th. Suggestion to OP: # ntpdate your.favorite.mirror.ntp.org Because to me it just looks like he might be a few multiples of 86400 seconds off. On a similar note, I wonder why you didn't complain that the new ELF binary was apparently built on Thu Jan 1 01:00:00 1970 :) cheers! mar77i

Carsten Mattner

6:29 p.m.

On Fri, Apr 28, 2017 at 12:40 PM, fnodeuser wrote:

...

Tobias Powalowski,

you continue to place pkgs in the testing repo that do not require any further testing.

for what reasons, exactly, do the linux 4.10.13 and hwids 20170328 pkgs need to be in testing for 4+ days?

also, you did not replace git:// with git+https:// in the hwids PKGBUILD file. github has HTTPS enabled for everything.

I have to get this off my chest, since the so called stable and lts kernel branches have failed to deliver what their name may promise. fnodeuser, I understand why you'd want kernel stable and lts updates to be pushed to core quicker, but the reality is that the criteria for what patches land in stable and even lts branches is lax. Like Florian said, stuff breaks in stable in lts kernel releases regularly. I myself don't understand why it's called stable or lts stable queue when it isn't strictly critical fixes, but I'm not the maintainer of the branches and may be missing the point. <A small rant> If you want a more stable kernel you can choose to use older lts branches like 4.1 or 3.16. Those get fewer updates. I mean, it doesn't help that Greg KH always appends the note All users of the 4.10 kernel series must upgrade while a stable kernel release adds regressions and random refactorings, not just critical fixes. It doesn't make sense to me, but the developers surely have their reasoning and customers to prove it makes sense. The constant churn of refactorings and whatnot makes it impossible for all the hardware that say i915 supports to actually work reliably across kernel releases. What used to work flawlessly in 4.1 can be broken in 4.4 because the devs do not test with Intel GPUs older than Gen7 for example, all the while claiming it's supported in the now refactored but practically untested code. It's not surprising that places with many Linux workstations run CentOS (Pixar) or Scientific Linux (CERN) or Ubuntu oldest LTS (Google). The main cause for the breakage is the linux kernel's desire to be monolithic and carry all drivers in-tree as much as possible for easier refactoring, which makes sense for developers but pushes users in need of stability to CentOS. The problem with a system like CentOS is that you can hope that a service pack release backports important new features, but you cannot pick and choose. In an OS like FreeBSD or Windows or a microkernel based system it's much easier and common to have core pieces that change annually or less often at best and have few modules that link against a stable ABI and can be fresh with new features. Think nVidia's drivers on FreeBSD or Windows. Windows has hopped onto the update often and break often train with version 10 but they still have a stable ABI like FreeBSD. The reality is that your hardware that worked in 4.10.3 can be broken in 4.10.8. I regularly look at the diffs of stable releases and fail to understand the selection process.

Eric Blau

7:11 p.m.

On Fri, Apr 28, 2017 at 12:29 PM, Carsten Mattner via arch-general wrote:

...

The constant churn of refactorings and whatnot makes it impossible for all the hardware that say i915 supports to actually work reliably across kernel releases. What used to work flawlessly in 4.1 can be broken in 4.4 because the devs do not test with Intel GPUs older than Gen7 for example, all the while claiming it's supported in the now refactored but practically untested code.

Carsten, I agree with you about i915. I've been hitting this kernel panic regularly, about once per day, freezing my entire machine: Bug 99295 - [Regression BDW] kernel panic in Intel i915 module, complete system freeze in 4.10-rc2 https://bugs.freedesktop.org/show_bug.cgi?id=99295 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. -Eric

Carsten Mattner

8:19 p.m.

On Fri, Apr 28, 2017 at 5:11 PM, Eric Blau wrote:

...

On Fri, Apr 28, 2017 at 12:29 PM, Carsten Mattner via arch-general wrote:

...
The constant churn of refactorings and whatnot makes it impossible for all the hardware that say i915 supports to actually work reliably across kernel releases. What used to work flawlessly in 4.1 can be broken in 4.4 because the devs do not test with Intel GPUs older than Gen7 for example, all the while claiming it's supported in the now refactored but practically untested code.

Carsten,

I agree with you about i915. I've been hitting this kernel panic regularly, about once per day, freezing my entire machine:

Bug 99295 - [Regression BDW] kernel panic in Intel i915 module, complete system freeze in 4.10-rc2 https://bugs.freedesktop.org/show_bug.cgi?id=99295

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. On one machine where XFCE, GNOME3 and Weston work without errors, I've seen Plasma to misbehave in its compositor so much that I couldn't get it to open KDE settings for turning off compositing. An earlier release of Plasma (4.x) used to work, so it's recently regressed. I attributed all of this to massive amount of churn in applications and the graphics stack without adequate GPU testing. It's great that we're now at OpenGL 4.3 levels of support in Mesa for some Intel GPUs, but when Plasma just doesn't render correctly, it's clear QA failed. Another bug with i915 and intel gpu stack is that DRI3 was supposed to solve all tearing issues and together with glamor one was supposed to use just generic modesetting instead of xf86-video-intel. The reality is that DRI2 with TearFree and AccelMethod SNA is the only reliable tear free mode. In DRI3 anytime you start video playback with mpv you can see how a small rectangle is resized to the final window size. This doesn't happen with DRI2. Some distros started to use generic modesetting by default, but I'd wager they didn't test for tearing and other functionality regressions or are used to and don't care about it. Since Wayland uses DRI3 by default, I've actually been able to observe tearing in Sway Wayland compositor, though very seldom. I wonder how the situation is with AMD and nVidia GPUs with open and closed driver stacks. 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. 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. 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.

Carsten Mattner

8:20 p.m.

Eric, does it also fail in XFCE or GNOME3? Like I wrote, I've found Plasma's compositor to be buggier.

Eric Blau

8:34 p.m.

On Fri, Apr 28, 2017 at 2:20 PM, Carsten Mattner wrote:

...

Eric, does it also fail in XFCE or GNOME3? Like I wrote, I've found Plasma's compositor to be buggier.

I use i3 with compton as a compositor. Maybe I would have better luck running 4.10.x without compton. I haven't tried that yet. I reverted back to linux-lts which seems to be running fine on my early 2015 MacBook Pro 12,x with the exception of a failed resume from hibernate every once and a while. -Eric

Eric Blau

8:43 p.m.

On Fri, Apr 28, 2017 at 2:19 PM, Carsten Mattner wrote:

...

On Fri, Apr 28, 2017 at 5:11 PM, Eric Blau wrote:

...
On Fri, Apr 28, 2017 at 12:29 PM, Carsten Mattner via arch-general 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.

...

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.

...

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.

...

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.

...

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. -Eric

Carsten Mattner

10 p.m.

On Fri, Apr 28, 2017 at 6:34 PM, Eric Blau wrote:

...

On Fri, Apr 28, 2017 at 2:20 PM, Carsten Mattner wrote:

...
Eric, does it also fail in XFCE or GNOME3? Like I wrote, I've found Plasma's compositor to be buggier.

I use i3 with compton as a compositor. Maybe I would have better luck running 4.10.x without compton. I haven't tried that yet.

I use XMonad with compton but GTK3 only works smoothly with Mutter's compositor or GDK's Wayland backend. Anything else flashes a black rectangle for any new window. A compositor is supposed to be required and enough, but compton or xfwm don't cut, though the glitch is less prevalent under xfwm. Now that Firefox has removed GTK2 support 53, there's no way around GTK3 anymore.

...

I reverted back to linux-lts which seems to be running fine on my early 2015 MacBook Pro 12,x with the exception of a failed resume from hibernate every once and a while.

Yeah or systemd requiring a newer kernel sometimes.

Carsten Mattner

10:11 p.m.

On Fri, Apr 28, 2017 at 6:43 PM, Eric Blau wrote:

...

On Fri, Apr 28, 2017 at 2:19 PM, Carsten Mattner wrote:

...
On Fri, Apr 28, 2017 at 5:11 PM, Eric Blau wrote:

...
On Fri, Apr 28, 2017 at 12:29 PM, Carsten Mattner via arch-general 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.

David C. Rankin

29 Apr 29 Apr

9:32 a.m.

On 04/28/2017 07:40 AM, fnodeuser wrote:

...

Tobias Powalowski,

you continue to place pkgs in the testing repo that do not require any further testing.

for what reasons, exactly, do the linux 4.10.13 and hwids 20170328 pkgs need to be in testing for 4+ days?

also, you did not replace git:// with git+https:// in the hwids PKGBUILD file. github has HTTPS enabled for everything.

Given the original reply address -- I smell a troll... -- David C. Rankin, J.D.,P.E.

Dragon ryu

9:55 a.m.

2017/04/29 午後4:32 "David C. Rankin" : On 04/28/2017 07:40 AM, fnodeuser wrote:

...

Tobias Powalowski,

you continue to place pkgs in the testing repo that do not require any further testing.

for what reasons, exactly, do the linux 4.10.13 and hwids 20170328 pkgs need to be in testing for 4+ days?

also, you did not replace git:// with git+https:// in the hwids PKGBUILD file. github has HTTPS enabled for everything.

Given the original reply address -- I smell a troll... -- David C. Rankin, J.D.,P.E. Uhm. I think topic are necro'd. ... I suggest close this thing, OP.

Eli Schwartz

30 Apr 30 Apr

3:58 a.m.

On 04/28/2017 09:21 AM, Florian Pritz via arch-general wrote:

...

I have put you on moderation. If you continue annoying us like this there will be further consequences. Consider this your final warning. There will not be another.

Florian, Well, as you can see from https://lists.archlinux.org/pipermail/arch-general/2017-April/043634.html that didn't work so well... This is an ongoing problem with this person and that website, see for example: https://lists.archlinux.org/pipermail/arch-general/2016-December/042780.html https://lists.archlinux.org/pipermail/arch-general/2016-December/042791.html Every time he posts stuff to the mailing lists, he uses disposable email addresses from binkmail.com, one of Mailinator's alternate domains (for places that have sensibly blacklisted mailinator.com) which is a sign of incredible ill faith in addition to willfully breaking thread flow. If you want to moderate him, you will have to block the whole domain (as I have requested multiple times before). This is a reasonable thing to do and is no loss whatsoever, because again, binkmail.com is nothing but an alternate domain for a *disposable email address* service. -- Eli Schwartz

2551

Age (days ago)

2553

Last active (days ago)

List overview

Download

14 comments

9 participants

participants (9)

Carsten Mattner
David C. Rankin
Dragon ryu
Eli Schwartz
Eric Blau
Florian Pritz
fnodeuser
Genes Lists
Martin Kühne