<html>
<head>
<meta http-equiv="Content-Type" content="text/html; charset=UTF-8">
</head>
<body>
<div class="moz-cite-prefix">Am 16.09.22 um 13:00 schrieb Dawid
Wrobel:<br>
</div>
<blockquote type="cite"
cite="mid:CANO8mVJBkkXv5gdmSx4XkGSd-YEUZH2CJOTV0SnTUBWt-8e1RA@mail.gmail.com">
<meta http-equiv="content-type" content="text/html; charset=UTF-8">
<div dir="ltr">
<div dir="ltr">On Thu, Sep 15, 2022 at 11:59 PM Johannes
Zarl-Zierl <<a href="mailto:johannes@zarl-zierl.at"
moz-do-not-send="true" class="moz-txt-link-freetext">johannes@zarl-zierl.at</a>>
wrote:</div>
<div dir="ltr"><br>
</div>
<div class="gmail_quote">
<blockquote class="gmail_quote" style="margin:0px 0px 0px
0.8ex;border-left-width:1px;border-left-style:solid;border-left-color:rgb(204,204,204);padding-left:1ex">Is
the launcher category the same as on <a
href="https://apps.kde.org/" rel="noreferrer"
target="_blank" moz-do-not-send="true"
class="moz-txt-link-freetext">https://apps.kde.org/</a>?
If so, I would <br>
strongly prefer to use that as well. From a user
perspective, <a href="http://apps.kde.org" rel="noreferrer"
target="_blank" moz-do-not-send="true">apps.kde.org</a> <br>
should be the single source of truth.<br>
</blockquote>
<div><br>
</div>
<div>
<div dir="ltr">I know this was discussed to death dozens of
times before, but given this context, wouldn't it make
sense to devote <a href="http://bugs.kde.org"
moz-do-not-send="true">bugs.kde.org</a> to user-facing
applications (as in <a href="http://apps.kde.org/"
moz-do-not-send="true" class="moz-txt-link-freetext">http://apps.kde.org/</a>)
*only*, and move all the issues related to the underlying
libraries, frameworks, tooling, etc. to GitLab, hopefully
after migrating away from Phabricator as well?
<div><br>
</div>
<div>It is not uncommon for organizations to maintain two
kinds of bug trackers: one for end-users, and one
internal, hiding the technical discussion away. I am
sure this would improve developers' workflow while
making <a href="http://bugs.kde.org"
moz-do-not-send="true">bugs.kde.org</a> less
intimidating to end-users. Cause if I was coming from
Windows/macOS and saw something like this:</div>
<div><br>
</div>
<div>- KDE apps<br>
- KDE Plasma Desktop<br>
- KDE Plasma Mobile<br>
- KDE Frameworks<br>
- KDE Neon<br>
</div>
<div><br>
</div>
<div>, I still would be confused as hell. I mean how many
KDE users are familiar with what Plasma
(Desktop/Mobile), Frameworks or Neon are? Let's bear in
mind that many of them use KDE apps individually on
non-Linux platforms.</div>
<div><br>
</div>
<div>Just my 2c.</div>
</div>
</div>
</div>
</div>
</blockquote>
<p>Hi,</p>
<p>you are on to something that I wanted to raise anyway: Quite
often people report bugs for a frameworks they think is related to
the problem instead of the product we expect them to use. Some
examples:</p>
<p>- kwindowystem or kwayland instead of kwin</p>
<p>- pulseaudio-qt instead of plasma-pa</p>
<p>- bluez-qt instead of bluedevil</p>
<p>- networkmanager-qt instead of plasma-nm</p>
<p>- knotifications instead of plasmashell | notifications</p>
<p>Separating these "internal" components a bit from the user-facing
products could make sense to reduce the apparent confusion.</p>
<p>However, I don't think using an entirely separate (and
different!) system for app bugs (bugzilla) and library bugs
(Gitlab Issues) is a good idea. Those two are somewhat different
in their workflows and capabilities (each having pros and cons)
and I doubt having to deal with *both* would be challenging. For
example think about moving bugs between the two systems.</p>
<p>Cheers</p>
<p>Nico<br>
</p>
</body>
</html>