[Users] Claws Mail with LXDE and LXQt desktops

[Dave Howorth]

On Tue, 29 Sep 2020 11:38:34 +0200
Michael Schwendt <bugs.michael at gmx.net> wrote:

> On Tue, 29 Sep 2020 01:52:40 +0100, Dave Howorth wrote:
> 
> > I answered that in the text just below. (emphasis now added)  
> 
> That would be the holy grail then. Given that Claws Mail doesn't
> crash for some of the found test-cases, analysis/discussion of the
> crash ought to start with guys that may be intimately familiar with
> the desktop environments used in those test-cases. And in the case of
> GTK2, it doesn't get much love anymore compared with GTK3.
> 
> > > It may be more than one distribution.  
> >
> > Indeed, but we only know of one at present, and nobody else has come
> > forward to say they are experiencing these problems elsewhere.  
> 
> Well, how many have encountered the crash? Switching desktop theme
> while Claws Mail is running isn't anything that can't be avoided
> easily. Personally, I have never heard about that crash before and
> also don't know whether it exists for a long time already.

Well I for one tried to reproduce the crash here (openSUSE Leap 15.0,
claws 3.16.0, LXDE desktop) and failed. But I don't understand your
point. How does it try to change the meaning of what I wrote?

> > But in the case of distro-supplied packages, it is usual to report
> > possible bugs to the distro in the first instance, and it is up to
> > the distro to receive such reports, confirm and triage them, assign
> > them to the correct support area (e.g. package maintainer), and
> > resolve the problem locally or escalate to an appropriate upstream.
> > Note that I have no knowledge of fedora specifically.  
> 
> There's an awful lot of theory in that paragraph, which may apply to
> commercial distributors, who maintain a controlled set of system
> component packages with a service level agreement, but it doesn't
> apply to a large scale community package collection. You expect
> community distro packagers to be more familiar with multiple system
> components than, for example, upstream developers. You also expect
> them to have access to test environments that would match the bug
> reporters setup.

I expect upstream developers not to have specific knowledge of
particular distros and to be unwilling to set up a test environment to
replicate the problem, let alone try to solve it. They are more likely
instead to request the user to build a test environment using the latest
version of their component instead of the distro-supplied version.
Strangely, that's usually not what end users either want to do or are
qualified to do.

> > > Serving as a proxy between a bug reporter and several bug trackers
> > > doesn't scale well.  
> >
> > Sorry I don't understand what you're saying here.  
> 
> Assume a ticket has been dumped into Fedora bugzilla in a
> semi-automated way using the Automatic Bug Reporting Tool, which is
> what quite some users do these days without adding details on
> reproducibility. The assignee of the ticket takes a look and
> concludes that the bug report ought to be discussed somewhere else.
> Now the ball is back in the court of the bug reporter to go
> elsewhere,

This is where we disagree. The assignee can't pass it back to the OP -
they are an end-user, not a qualified software person. They don't have
the necessary skills. The packager should refer it to another packager,
or three.

Maybe this explains why I know nothing about fedora :)

> possibly subscribe to a mailing-list or open an account in
> an upstream tracker, as to continue there and to be available as to
> answer questions. It is wrong to assume that the distro packager can
> take over all that. In the case of subject, LXDE/LXQT/XFCE/Mate are
> completely unrelated to Claws Mail.
> 
> > I would expect that Fedora's Claws Mail packagers would determine
> > where the problem lay and reassign the bug to the appropriate
> > Fedora package. The Fedora packagers should contact upstream if
> > necessary by default, not the OP, since they are better placed to
> > explain where the problem has been located and to integrate and
> > test the fix.  
> 
> Nobody is "better placed", unless it's someone with intimate knowledge
> of the used components/frameworks/DEs and enough spare time at hand
> to contribute something. What may be necessary to fix it is not known
> yet.
> 
> For one of the two bugs that have lead to this topic I have given
> some background before. You need to read the few comments, though,
> also the one for the libX11 merge request:
> https://bugs.launchpad.net/ubuntu/+source/gtk+2.0/+bug/1808710
> _______________________________________________
> Users mailing list
> Users at lists.claws-mail.org
> https://lists.claws-mail.org/cgi-bin/mailman/listinfo/users