Tobias Powalowski and his nonsensical maintenance decisions

classic Classic list List threaded Threaded
15 messages Options
Reply | Threaded
Open this post in threaded view
|

Tobias Powalowski and his nonsensical maintenance decisions

fnodeuser-2
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.
Reply | Threaded
Open this post in threaded view
|

Re: Tobias Powalowski and his nonsensical maintenance decisions

arch general mailing list-2
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


signature.asc (875 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: Tobias Powalowski and his nonsensical maintenance decisions

arch general mailing list-2


   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
[hidden email]
Reply | Threaded
Open this post in threaded view
|

Re: Tobias Powalowski and his nonsensical maintenance decisions

arch general mailing list-2
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
Reply | Threaded
Open this post in threaded view
|

Re: Tobias Powalowski and his nonsensical maintenance decisions

arch general mailing list-2
In reply to this post by fnodeuser-2
On Fri, Apr 28, 2017 at 12:40 PM, fnodeuser <[hidden email]> 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.

</A small rant>
Reply | Threaded
Open this post in threaded view
|

Re: Tobias Powalowski and his nonsensical maintenance decisions

Eric Blau
On Fri, Apr 28, 2017 at 12:29 PM, Carsten Mattner via arch-general
<[hidden email]> 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
Reply | Threaded
Open this post in threaded view
|

Re: Tobias Powalowski and his nonsensical maintenance decisions

arch general mailing list-2
On Fri, Apr 28, 2017 at 5:11 PM, Eric Blau <[hidden email]> wrote:

> On Fri, Apr 28, 2017 at 12:29 PM, Carsten Mattner via arch-general
> <[hidden email]> 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.
Reply | Threaded
Open this post in threaded view
|

Re: Tobias Powalowski and his nonsensical maintenance decisions

arch general mailing list-2
Eric, does it also fail in XFCE or GNOME3? Like I wrote, I've found
Plasma's compositor to be buggier.
Reply | Threaded
Open this post in threaded view
|

Re: Tobias Powalowski and his nonsensical maintenance decisions

Eric Blau
On Fri, Apr 28, 2017 at 2:20 PM, Carsten Mattner
<[hidden email]> 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
Reply | Threaded
Open this post in threaded view
|

Re: Tobias Powalowski and his nonsensical maintenance decisions

Eric Blau
In reply to this post by arch general mailing list-2
On Fri, Apr 28, 2017 at 2:19 PM, Carsten Mattner
<[hidden email]> wrote:

> On Fri, Apr 28, 2017 at 5:11 PM, Eric Blau <[hidden email]> wrote:
>> On Fri, Apr 28, 2017 at 12:29 PM, Carsten Mattner via arch-general
>> <[hidden email]> 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
Reply | Threaded
Open this post in threaded view
|

Re: Tobias Powalowski and his nonsensical maintenance decisions

arch general mailing list-2
In reply to this post by Eric Blau
On Fri, Apr 28, 2017 at 6:34 PM, Eric Blau <[hidden email]> wrote:
> On Fri, Apr 28, 2017 at 2:20 PM, Carsten Mattner
> <[hidden email]> 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.
Reply | Threaded
Open this post in threaded view
|

Re: Tobias Powalowski and his nonsensical maintenance decisions

arch general mailing list-2
In reply to this post by Eric Blau
On Fri, Apr 28, 2017 at 6:43 PM, Eric Blau <[hidden email]> wrote:

> On Fri, Apr 28, 2017 at 2:19 PM, Carsten Mattner
> <[hidden email]> wrote:
>> On Fri, Apr 28, 2017 at 5:11 PM, Eric Blau <[hidden email]> wrote:
>>> On Fri, Apr 28, 2017 at 12:29 PM, Carsten Mattner via arch-general
>>> <[hidden email]> 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.
Reply | Threaded
Open this post in threaded view
|

Re: Tobias Powalowski and his nonsensical maintenance decisions

David C. Rankin
In reply to this post by fnodeuser-2
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.
Reply | Threaded
Open this post in threaded view
|

Re: Tobias Powalowski and his nonsensical maintenance decisions

arch general mailing list-2
2017/04/29 午後4:32 "David C. Rankin" <[hidden email]>:

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.
Reply | Threaded
Open this post in threaded view
|

Re: Tobias Powalowski and his nonsensical maintenance decisions

arch general mailing list-2
In reply to this post by arch general mailing list-2
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


signature.asc (849 bytes) Download Attachment