Re: Plasm 6.1 Kickoff Meeting notes

2024-03-12 Thread Neal Gompa 
On Mon, Mar 11, 2024 at 9:32 AM Nicolas Fella  wrote:
>
> # Plasma 6.1 kickoff meeting notes
>

Hey sorry folks, I wasn't able to make it because I'm in California
this week and that resulted in it being too early for me.

> ## 6.0 retrospective
>
> Generally well received# Plasma 6.1 kickoff meeting notes
>
> ## 6.0 retrospective
>
> Generally well received
>
> Problems:
> - Neon's rollout was/still is bumpy. Needs retrospective from Neon
> developers on what happend
> - Nvidia:
>  - Missing configuration to enable modesetting (downstream issue)

At least in RPM Fusion (for Fedora), the driver package patches the
defaults to enable modesetting by default:
http://pkgs.rpmfusion.org/cgit/nonfree/nvidia-kmod.git/tree/make_modeset_default.patch

Maybe this needs to be recommended to distributors that offer the NVIDIA driver.

>  - Missing implicit sync makes XWayland glitchy (upstream issue).
> Potentially backportable patches exist
>  - Resume from suspend broken. Some kernel-level thing exists
> (NVreg_PreserveVideoMemoryAllocations), needs research/documentation
>
> ## 6.1 release planning
>
> Idea: Keep the megarelese? No strong benefit, unless there was a unified
> LTS release
>

The MegaRelease has been incredibly valuable from the Fedora
perspective because it gives us a collection of things that we can
reasonably expect to qualify and coordinate with upstream on. I would
personally like to see this continue for feature releases.

> Goals for the release planning:
>   - Keep time to next feature release short to allow for gaps in
> (Wayland) feature set to close quickly
>   - Align with fall/October releases of distros
>   - More extensive beta releases
>
> Tentative idea:
>   - 6.1 in June
>   - Two Betas
>   - Slightly extend support window for the release to avoid gap between
> 6.1 ending and distros picking up 6.2
>   - Needs coordination with distros before finalizing
>

I know we've discussed this in a few avenues before, but I'll continue
to suggest January/July to have the beta releases and February/August
for the final releases. This lines up with Fedora, Kubuntu, and
openSUSE cutoffs in their release schedules.

(And while I think we shouldn't do Plasma LTS releases, since we are,
I think those should be done in the "spring" Plasma releases to align
with Kubuntu LTS and openSUSE Leap schedules.)

> Dependencies (business as usual):
>   - Qt 6.7
>   - Frameworks as of Beta date
>
> Feature/work item ideas:
>   - David R: Emulated Input integration
>   - Marco: Work on tiling features, folderview refactoring
>   - Nico: Wayland a11y and graphics tablet work, QML tooling
>   - Kai: New Fonts KCM/tools
>   - Vlad: Work on Rendering in KWin
>   - Jakob: Mouse gestures, per-monitor brightness
>   - Niccolo: Floating dialogs, icons, 2D gestures
>

This is all very exciting stuff! I think Xaver mentioned that he's
looking at getting the xdg-color-management protocol implemented, and
David E had talked to me about session management stuff. Are those
still in the cards for 6.1?

> # Sprint
>
> We want a sprint sometime soon. There's a megasprint planned for April,
> avoid doing something too close to it to avoid travel overload.
>
> Summer might be a better time.
>
> Needs someone to volounteer organizing
>

Thanks for the minutes on this meeting. :)



--
真実はいつも一つ！/ Always, there's only one truth!

Re: more betas / shorter windows?

2023-12-23 Thread Neal Gompa 
On Mon, Dec 18, 2023 at 2:22 PM Nate Graham  wrote:
>
> Yeah, it's long been a problem that bugs reported towards the end of a
> beta release were often fixed weeks ago, which wastes everyone's time.
> Shorter betas would also help our most effective volunteer QA people who
> close their bug reports once they're fixed by us (like Patrick Silva and
> some others) do so at a more rapid pace.
>
> I'd support one-week betas, or if we think that's too aggressive and too
> much work for everyone, then two weeks.
>

It takes, on average, about a week for us in Fedora to get everything
in and validated. I suspect other distributions are similar. Making it
too short risks making it too hard for us to keep up.




--
真実はいつも一つ！/ Always, there's only one truth!

Re: git-repositories-for-release

2023-11-06 Thread Neal Gompa 
On Mon, Nov 6, 2023 at 11:21 AM Jonathan Riddell  wrote:
>
> Diff from 5.27
> -aura-browser
> -aura-browser
> +kactivities
> +kactivities-stats
> -khotkeys
> -krdp
> +kwayland
> -plank-player
> -plank-player
> -plasma-bigscreen
> +plasma-framework
> -plasma-remotecontrollers
> +plasma5support
> +print-manager
> +wacomtablet
>
> Complete list:
>
> bluedevil
> breeze
> breeze-grub
> breeze-gtk
> breeze-plymouth
> discover
> drkonqi
> flatpak-kcm
> kactivities
> kactivities
> kactivities-stats
> kactivities-stats
> kactivitymanagerd
> kde-cli-tools
> kde-gtk-config
> kdecoration
> kdeplasma-addons
> kgamma
> kinfocenter
> kmenuedit
> kpipewire
> kscreen
> kscreenlocker
> ksshaskpass
> ksystemstats
> kwallet-pam
> kwayland
> kwayland-integration
> kwin
> kwrited
> layer-shell-qt
> libkscreen
> libksysguard
> milou
> ocean-sound-theme
> oxygen
> oxygen-sounds
> plasma-browser-integration
> plasma-desktop
> plasma-disks
> plasma-firewall
> plasma-framework
> plasma-framework
> plasma-integration
> plasma-mobile
> plasma-nano
> plasma-nm
> plasma-pa
> plasma-sdk
> plasma-systemmonitor
> plasma-thunderbolt
> plasma-vault
> plasma-welcome
> plasma-workspace
> plasma-workspace-wallpapers
> plasma5support
> plymouth-kcm
> polkit-kde-agent-1
> powerdevil
> print-manager
> print-manager
> qqc2-breeze-style
> sddm-kcm
> systemsettings
> wacomtablet
> wacomtablet
> xdg-desktop-portal-kd
>

Not that it's terribly important to me, but some of these have
duplicate entries. Is that going to have "interesting" impacts on your
automation?


-- 
真実はいつも一つ！/ Always, there's only one truth!

Re: First round of feedback from Fedora 40 KDE Plasma 6 (Wayland-only) discussion

2023-10-30 Thread Neal Gompa 
On Thu, Sep 21, 2023 at 8:11 PM Neal Gompa  wrote:
>
> On Wed, Sep 20, 2023 at 8:53 AM Niels De Graef  wrote:
> >
> > Hi everyone,
> >
> > Thanks Neal for including me!
> >
>
> Thanks for joining in the conversation!
>
> > (For the people who don't know me, I work for Red Hat as the product
> > owner in the GPU team, which has maintained (and some time ago
> > deprecated) Xorg, as well as maitning other graphics APIs such as
> > Wayland, OpenGL, Vulkan etc. I'm also a GNOME contributor in my free
> > time and sometimes do Wayland advocacy in local communities.)
> >
> > I'll put my answers inline so we can keep things a bit structured here.
> >
> > On Mon, Sep 18, 2023 at 6:45 AM Neal Gompa  wrote:
> > >
> > > Hey all,
> > >
> > > So unless you've been living under a rock for the past week, you might
> > > have noticed a bunch of buzz about Fedora KDE proposing to drop the
> > > X11 session with Plasma 6[1]. Those of you who were at Akademy last
> > > year[2] or this year[3] knew that this was coming. For the rest of
> > > you... 來
> > >
> > > Over the past few days, I've gotten a deluge of use-cases and needs
> > > that would be useful to sort through and figure out actions to move
> > > forward on. Some of them, I've got ideas, others less so.
> >
> > Before deep-diving: thanks for writing this up! It's good to have some
> > discussions going on each topic
> >
> > > The first thing that came up was that KiCad seems to need help and has
> > > had a bad experience interfacing with some folks over resolving their
> > > issues moving into a Wayland world.
> > > * 
> > > https://lists.fedoraproject.org/archives/list/de...@lists.fedoraproject.org/message/6KLDR4WM7PMJ7VJTP4LH2HA4RAMCR6UJ/
> > > * 
> > > https://groups.google.com/a/kicad.org/g/devlist/c/-glHquy0b20/m/nSBa_ntOAAAJ
> > > I don't have any particular suggestions here, though David Edmundson
> > > mentioned in the Fedora KDE Matrix room the idea of creating a new
> > > protocol to support their particular need of positioning and plumbing
> > > it through to Qt so that wxQt can use it. Also, some dedicated
> > > outreach might be a good idea to get them to be more amenable to the
> > > Wayland world.
> >
> > In terms of general outreach to the KiCad project: I looked into it a
> > while ago after a friend of mine pointed out that they thought it was
> > a shame it didn't have Wayland support.
> >
> > Basically, the community had closed the issue for Wayland support as
> > WONTFIX due to the belief that Wayland wouldn't fix their issues, so I
> > tried to clear up some of the confusion:
> > https://gitlab.com/kicad/code/kicad/-/issues/7207#note_1356840266 . At
> > the very least it _looks_ like things improved since then, but it
> > still needs a bit of "massaging" to keep mindsets in a positive
> > environment. At the very least, it seems like some of their features
> > might be unblocked, and they reopened the issue as well.
> >
> > FWIW: I'm a contributor to GIMP as well, and I had to work through a
> > similar mentality, where people have/had similar negative attitudes
> > towards Wayland. The problem is that also for them, it takes patience
> > and understanding the problems they face, as they fall into an "XY
> > problem" (https://en.wikipedia.org/wiki/XY_problem): "I need to have
> > global positioning" (which is a WONTFIX current for most Wayland
> > developers) vs "I want to restore the positions of my toplevel
> > windows" (which would be solved with the xdg-session-management
> > protocol that's proposed upstream).
> >
> > > Session restore has come up a few times. It actually came up during
> > > the initial discussion within the SIG too, and has come up again
> > > during the proposal discussion in Fedora.
> > > * https://pagure.io/fedora-kde/SIG/issue/347#comment-856399
> > > * 
> > > https://lists.fedoraproject.org/archives/list/de...@lists.fedoraproject.org/message/D76KHIPEPS6N7N3QHX6KBVDQ4RF5NVYO/
> > > GNOME designed a protocol for their use, can we reuse this as an
> > > initial way to solve this problem? What's stopping us from doing
> > > something here?
> >
> > In case anyone's interested, Philip Withnall (who worked on this) made
> > a blog post about it at
> > https://tecnocode.co.uk/2023/08/07/guadec-2023/ , which also contains
> > a link to the video & slides of his talk.
>

Re: First round of feedback from Fedora 40 KDE Plasma 6 (Wayland-only) discussion

2023-09-24 Thread Neal Gompa 
On Wed, Sep 20, 2023 at 8:53 AM Niels De Graef  wrote:
>
> Hi everyone,
>
> Thanks Neal for including me!
>

Thanks for joining in the conversation!

> (For the people who don't know me, I work for Red Hat as the product
> owner in the GPU team, which has maintained (and some time ago
> deprecated) Xorg, as well as maitning other graphics APIs such as
> Wayland, OpenGL, Vulkan etc. I'm also a GNOME contributor in my free
> time and sometimes do Wayland advocacy in local communities.)
>
> I'll put my answers inline so we can keep things a bit structured here.
>
> On Mon, Sep 18, 2023 at 6:45 AM Neal Gompa  wrote:
> >
> > Hey all,
> >
> > So unless you've been living under a rock for the past week, you might
> > have noticed a bunch of buzz about Fedora KDE proposing to drop the
> > X11 session with Plasma 6[1]. Those of you who were at Akademy last
> > year[2] or this year[3] knew that this was coming. For the rest of
> > you... 來
> >
> > Over the past few days, I've gotten a deluge of use-cases and needs
> > that would be useful to sort through and figure out actions to move
> > forward on. Some of them, I've got ideas, others less so.
>
> Before deep-diving: thanks for writing this up! It's good to have some
> discussions going on each topic
>
> > The first thing that came up was that KiCad seems to need help and has
> > had a bad experience interfacing with some folks over resolving their
> > issues moving into a Wayland world.
> > * 
> > https://lists.fedoraproject.org/archives/list/de...@lists.fedoraproject.org/message/6KLDR4WM7PMJ7VJTP4LH2HA4RAMCR6UJ/
> > * 
> > https://groups.google.com/a/kicad.org/g/devlist/c/-glHquy0b20/m/nSBa_ntOAAAJ
> > I don't have any particular suggestions here, though David Edmundson
> > mentioned in the Fedora KDE Matrix room the idea of creating a new
> > protocol to support their particular need of positioning and plumbing
> > it through to Qt so that wxQt can use it. Also, some dedicated
> > outreach might be a good idea to get them to be more amenable to the
> > Wayland world.
>
> In terms of general outreach to the KiCad project: I looked into it a
> while ago after a friend of mine pointed out that they thought it was
> a shame it didn't have Wayland support.
>
> Basically, the community had closed the issue for Wayland support as
> WONTFIX due to the belief that Wayland wouldn't fix their issues, so I
> tried to clear up some of the confusion:
> https://gitlab.com/kicad/code/kicad/-/issues/7207#note_1356840266 . At
> the very least it _looks_ like things improved since then, but it
> still needs a bit of "massaging" to keep mindsets in a positive
> environment. At the very least, it seems like some of their features
> might be unblocked, and they reopened the issue as well.
>
> FWIW: I'm a contributor to GIMP as well, and I had to work through a
> similar mentality, where people have/had similar negative attitudes
> towards Wayland. The problem is that also for them, it takes patience
> and understanding the problems they face, as they fall into an "XY
> problem" (https://en.wikipedia.org/wiki/XY_problem): "I need to have
> global positioning" (which is a WONTFIX current for most Wayland
> developers) vs "I want to restore the positions of my toplevel
> windows" (which would be solved with the xdg-session-management
> protocol that's proposed upstream).
>
> > Session restore has come up a few times. It actually came up during
> > the initial discussion within the SIG too, and has come up again
> > during the proposal discussion in Fedora.
> > * https://pagure.io/fedora-kde/SIG/issue/347#comment-856399
> > * 
> > https://lists.fedoraproject.org/archives/list/de...@lists.fedoraproject.org/message/D76KHIPEPS6N7N3QHX6KBVDQ4RF5NVYO/
> > GNOME designed a protocol for their use, can we reuse this as an
> > initial way to solve this problem? What's stopping us from doing
> > something here?
>
> In case anyone's interested, Philip Withnall (who worked on this) made
> a blog post about it at
> https://tecnocode.co.uk/2023/08/07/guadec-2023/ , which also contains
> a link to the video & slides of his talk.
>
> > Barrier/Input-Leap has come up as well. Seamless keyboard and mouse
> > handoff across computers is in demand.
> > * https://discussion.fedoraproject.org/t/89794/6
> > * https://invent.kde.org/plasma/xdg-desktop-portal-kde/-/issues/12
> > The necessary portal frontends have landed in xdg-desktop-portal and
> > so we're just missing the requisite backend in xdg-desktop-portal-kde.
>
> Just a quick note that Input Leap should be suppor

Re: First round of feedback from Fedora 40 KDE Plasma 6 (Wayland-only) discussion

2023-09-18 Thread Neal Gompa 
On Mon, Sep 18, 2023 at 8:42 AM David Edmundson
 wrote:
>
> On Mon, Sep 18, 2023 at 5:45 AM Neal Gompa  wrote:
> me of them, I've got ideas, others less so.
> >
> > The first thing that came up was that KiCad seems to need help and has
> > had a bad experience interfacing with some folks over resolving their
> > issues moving into a Wayland world.
>
> Given I'm quoted, I said we shouldn't rush clients to not be on Xwayland.
> These are just Kicad's known issues, it'll be longer to fix all the
> issues that come up after they're ported.
> That's what Xwayland is for, and we've put a lot of effort into it.
>

They seem to be under the impression that KiCad can't run effectively
under XWayland either and refuse to support it because of that. I'm
quite fine with convincing them to be comfortable with XWayland too.



--
真実はいつも一つ！/ Always, there's only one truth!

First round of feedback from Fedora 40 KDE Plasma 6 (Wayland-only) discussion

2023-09-18 Thread Neal Gompa 
Hey all,

So unless you've been living under a rock for the past week, you might
have noticed a bunch of buzz about Fedora KDE proposing to drop the
X11 session with Plasma 6[1]. Those of you who were at Akademy last
year[2] or this year[3] knew that this was coming. For the rest of
you... 來

Over the past few days, I've gotten a deluge of use-cases and needs
that would be useful to sort through and figure out actions to move
forward on. Some of them, I've got ideas, others less so.

The first thing that came up was that KiCad seems to need help and has
had a bad experience interfacing with some folks over resolving their
issues moving into a Wayland world.
* 
https://lists.fedoraproject.org/archives/list/de...@lists.fedoraproject.org/message/6KLDR4WM7PMJ7VJTP4LH2HA4RAMCR6UJ/
* https://groups.google.com/a/kicad.org/g/devlist/c/-glHquy0b20/m/nSBa_ntOAAAJ
I don't have any particular suggestions here, though David Edmundson
mentioned in the Fedora KDE Matrix room the idea of creating a new
protocol to support their particular need of positioning and plumbing
it through to Qt so that wxQt can use it. Also, some dedicated
outreach might be a good idea to get them to be more amenable to the
Wayland world.

Session restore has come up a few times. It actually came up during
the initial discussion within the SIG too, and has come up again
during the proposal discussion in Fedora.
* https://pagure.io/fedora-kde/SIG/issue/347#comment-856399
* 
https://lists.fedoraproject.org/archives/list/de...@lists.fedoraproject.org/message/D76KHIPEPS6N7N3QHX6KBVDQ4RF5NVYO/
GNOME designed a protocol for their use, can we reuse this as an
initial way to solve this problem? What's stopping us from doing
something here?

Barrier/Input-Leap has come up as well. Seamless keyboard and mouse
handoff across computers is in demand.
* https://discussion.fedoraproject.org/t/89794/6
* https://invent.kde.org/plasma/xdg-desktop-portal-kde/-/issues/12
The necessary portal frontends have landed in xdg-desktop-portal and
so we're just missing the requisite backend in xdg-desktop-portal-kde.

Something that was a little surprising to find out is that kwin's
support for the number pad seems to be in less than ideal condition.
* 
https://lists.fedoraproject.org/archives/list/de...@lists.fedoraproject.org/message/5VHB34MWX5UTJE3CLOINE6OBREQIX4RY/
This doesn't seem huge to fix, but I don't know a lot about key maps...

A rather dominating part of the discussion has been color management
(or the current lack thereof).
* https://discussion.fedoraproject.org/t/89794/12
* https://discuss.kde.org/t/fedora-kde-40-plans-to-completely-drop-x11/5047
* https://invent.kde.org/plasma/kwin/-/issues/11
This one seems to have been dragging on upstream in wayland-protocols
for years now. Could we consider shipping the draft as a kde
namespaced protocol (similar to what the Chrome OS folks did for
aura-shell) and migrating to the finalized version later?
(As a sidebar, I'm extremely disappointed in how poorly
wayland-protocols governance is going right now. I count seven
wayland-protocols proposed by folks I know are from KDE that are in
varying states of being stuck, with all but three 6+ months old and in
varying levels of decay. This is seriously hampering the development
of Plasma Wayland from my point of view. And it's not just protocols
from KDE that benefit KDE. Even ones from GNOME developers that we
want are in similar ruts.)

The lack of functioning support for host-guest clipboard copy-paste in
Plasma Wayland with SPICE was also brought up as a problem. Not just
for regular virtualization use, but also because it hampers testing
workflows.
* 
https://lists.fedoraproject.org/archives/list/de...@lists.fedoraproject.org/message/AERH56JOMVKMNJA6MDKCFFC7DKGIRV53/
* https://bugzilla.redhat.com/show_bug.cgi?id=2016563
* https://gitlab.freedesktop.org/spice/linux/vd_agent/-/issues/26
I am not sure what should be done here, but it clearly kind of sucks
to have this problem. It's not currently on our list of Plasma Wayland
"Showstoppers", maybe it should be listed there?

Semi-related but not necessarily in the land of KDE, I got feedback on
the Fediverse about the lack of a method for pre-authorizing
applications to access portals means that certain classes of
applications are functionally impossible to use in a Wayland
environment. The example I was given was Veyon, which allows teachers
to control school computer labs and monitor them while they're in use.
This is a much more interesting variation of the automatic headless
remote integration case for IT support systems software.
* https://mastodon.tedomum.net/@lebout2canap/111074670912414830
* https://github.com/flatpak/xdg-desktop-portal/issues/1105
This is probably a solution that needs to be handled at the
xdg-desktop-portal level, but I wanted to highlight it here for
everyone.

So you might think that with this list that it's all bad news, but
it's not! The good news is that most of these were already

Re: C++/library requirements for Plasma 5.26

2022-07-09 Thread Neal Gompa 
On Thu, Jul 7, 2022 at 8:09 AM Nicolas Fella  wrote:
>
> Hi,
>
> for Plasma 5.26 I would like to make use of some C++20 features, in
> particular coroutines.
>
> In terms of compiler requirements this should translate to requiring GCC
> 10 or Clang 11.
>
> In addition we would like to require the qcoro library
> (https://github.com/danvratil/qcoro). As per
> https://github.com/danvratil/qcoro/issues/85 the library can be
> considered stable and is regularly released.
>
> Is there any distribution that plans to ship Plasma 5.26 that cannot
> fulfill these requirements?
>
> To test whether your system provides the necessary bits you can try
> building
> https://invent.kde.org/plasma/plasma-desktop/-/merge_requests/1023 or
> https://invent.kde.org/plasma/plasma-nm/-/merge_requests/124
>
> Let me know of there are any problems with this plan.
>

As far as I can tell, we shouldn't have any problems with Fedora or
RHEL/CentOS 9. RHEL/CentOS 9 uses GCC 11 and all currently supported
Fedora releases are GCC 11 or newer.

We will no longer be able to offer updated versions of KDE Plasma for
RHEL/CentOS 8 (GCC 8), though we might stop doing it anyway if we
can't figure out how to work around the need for newer wayland and
wayland-protocols.



--
真実はいつも一つ！/ Always, there's only one truth!

Request for help for developing new XDG StatusNotifier/AppIndicator spec for KDE+GNOME

2022-01-17 Thread Neal Gompa 
Hello all,

As many of you know, I am one of the leads for the Fedora KDE Special
Interest Group (SIG), which develops the Fedora KDE spin[1] and the
new Fedora Kinoite[2]. What you may not know is that I'm also a member
of the Fedora Workstation Working Group (WG), which develops the
Fedora Workstation Edition[3] and Fedora Silverblue[4].

The Fedora Workstation WG has become convinced we need to have status
notifiers supported in GNOME in order to properly support
cross-platform applications that leverage status notifiers as core to
using them. However, the GNOME developers are not interested in
supporting the existing KSNI/AppIndicator specification due to several
perceived issues around sandboxed applications. In order to resolve
these issues and finally standardize the method in which all desktops
support status notifiers, I would like to invite interested folks
maintaining and developing KSNI in KDE Plasma to help us develop the
spec to unify support around status notifiers in KDE Plasma and GNOME.

The new specification development has been kicked off with an issue on
the xdg-specs repository:
https://gitlab.freedesktop.org/xdg/xdg-specs/-/issues/84

Most of the detailed background information is linked from the
xdg-specs issue, so I encourage you to read that for more information.

If you have any questions, concerns, or comments, feel free to reply and ask.

Thanks in advance and best regards,
Neal


[1]: https://kde.fedoraproject.org/
[2]: https://kinoite.fedoraproject.org/
[3]: https://getfedora.org/workstation/
[4]: http://silverblue.fedoraproject.org/

--
真実はいつも一つ！/ Always, there's only one truth!

Re: Using C++20 in Plasma

2021-08-07 Thread Neal Gompa 
On Fri, Aug 6, 2021 at 7:06 AM Nicolas Fella  wrote:
>
> Hi,
>
> I would like to explore whether it would be feasible from a distribution
> POV to use C++20 in Plasma (and other non-Frameworks projects).
>
> In practical terms this would mean something like requiring gcc 10 or
> clang 10 (the exact version that supports a given standard is hard to
> define precisely, but these versions seem to have a reasonable coverage).
>
> Is there any distro planning to ship future Plasma releases that does
> not have gcc 10 or clang 10?
>

>From the Red Hat family side, Fedora 34 uses GCC 11, so we're fine
there. Red Hat Enterprise Linux 8 uses GCC 8 by default, but GCC 10 is
available with the gcc-toolset-10 metapackage.

>From the SUSE family side, openSUSE Leap 15 uses GCC 7 by default, but
offers GCC 10 as an alternative with the gcc10 package.




-- 
真実はいつも一つ！/ Always, there's only one truth!

Re: Can we consider bumping up the Plasma 5.23 release by one week?

2021-06-25 Thread Neal Gompa 
On Fri, Jun 25, 2021 at 9:38 AM David Edmundson
 wrote:
>
> We discussed this some more, and we are not in favour of moving
> forwards for Fedora:
>
> Reasons given were:
>  - It either cuts into our beta period, or causes us issues with
> framework releases.
>  - Fedora has regular releases anyway
> - It collides with the promo plans above
>  - .0 releases tend to not be a great UX anyway
>

The major issue (for us) with not pulling the Plasma 5.23 schedule[1]
up to align it better with the Fedora Linux 35 schedule[2] is that we
simply can't offer Plasma 5.23 during F35 Beta or F35 Final. A big
part of why I was comfortable with switching to Wayland by default[3]
for Fedora Linux 34 was that I was shipping the latest in-development
release at that time. Looking at the schedule now, we're basically
going to have to sit out of Plasma 5.23 like we did for Plasma 5.20
(we shipped Plasma 5.19.5 with Fedora Linux 33 GA and shipped Plasma
5.20 as an update a month later).

Ironically, this would be less of a problem if we weren't shipping
Wayland by default now... :P

At least it looks like the Plasma 5.23 Beta release is after the
branch period, so we can probably introduce it into Rawhide and
attempt to promote Rawhide during the beta period...

(As an aside, it seems weird to expect that .0 release to be bad...)

[1]: https://community.kde.org/Schedules/Plasma_5
[2]: https://fedorapeople.org/groups/schedule/f-35/f-35-key-tasks.html
[3]: https://fedoraproject.org/wiki/Changes/WaylandByDefaultForPlasma



-- 
真実はいつも一つ！/ Always, there's only one truth!

Re: About some old and hard to maintain effects

2021-06-01 Thread Neal Gompa 
On Mon, May 31, 2021 at 10:22 AM Vlad Zahorodnii  wrote:
>
> On 5/31/21 4:43 PM, Aleix Pol wrote:
> > Do you think these effects could be implemented using other
> > non-deprecated abstractions?
>
> Yes. Those effects need to render every animated window into an
> offscreen texture and then do their thing, e.g. map the offscreen
> texture on a cube or a cylinder, etc. The mechanics of getting the
> offscreen texture will possibly change as we progress with the scene
> redesign though.
>

I personally would be very sad if we lost those effects. I still use
the cube effect to dazzle people. :P

And yes, I still use it on one of my machines because I love being fancy. :)



--
真実はいつも一つ！/ Always, there's only one truth!

Re: Consistent CMake requirements in Plasma

2021-02-12 Thread Neal Gompa 
On Tue, Feb 9, 2021 at 1:32 PM Nicolas Fella  wrote:
>
> Hi,
>
> while I was doing some cmake cleanup in Plasma I noticed that our stated
> minimum cmake versions are both somewhat inconsistent and super old.
> Most Plasma projects state that either 2.8 (released in 2009) or 3.0
> (released in 2014) are the minimum. That's obviously unrealistic.
>
> Newer cmake versions offer some nice stuff such as imported targets for
> common libs (e.g. used in
> https://invent.kde.org/plasma/plasma-desktop/-/merge_requests/336). For
> the sake of consistency I propose that we standardize Plasma on
> something recent-ish.
>
> My candidate for this would be cmake 3.16. It's the version shipped by
> Ubuntu 20.04 and thus Neon. This would exclude Debian stable which ships
> 3.13 (which does not have the feature relevant for
> https://invent.kde.org/plasma/plasma-desktop/-/merge_requests/336).
>
> Thoughts?
>

While at the moment I don't think we can ship newer Plasma to Fedora
EPEL for RHEL/CentOS 8 due to Qt things, we should be fine from a
CMake point of view as RHEL 8.4 is rebasing from CMake 3.11 to CMake
3.18. :)

Fedora is obviously fine. :)



--
真実はいつも一つ！/ Always, there's only one truth!

Re: Synchronized release schedule for Plasma

2020-11-26 Thread Neal Gompa 
On Thu, Nov 26, 2020 at 10:25 AM Aleix Pol  wrote:
>
> On Tue, Nov 24, 2020 at 5:10 PM David Edmundson  
> wrote:
>>>
>>> As distribution package maintainers, we would like Plasma developers to 
>>> slightly alter the release schedule to align releases with a more 
>>> distribution friendly cycle. You could consider shortening one release 
>>> cycle (and then keep the 6 month schedule) to align releases.
>>
>>
>> We have in the past shuffled things slightly to line up things up with 
>> distros on request, particularly LTS releases. We can certainly explore that 
>> on a one-off basis.
>>
>> >With this schedule in place, we would also benefit from more beta releases 
>> >over a slightly longer period. They would be packaged into the beta and RC 
>> >releases of those distributions thus enabling more pre-release testing.
>>
>> We did have 6 month release cycles in the past.
>>
>> The rationale for moving at the time was twofold:
>>  - people rushed in changes towards the feature freeze as otherwise it would 
>> be aages till their changes reached users
>>  - the more changes we have in a release, the more testing and inevitable 
>> regression fixes we need to do, spreading that out should result in things 
>> being more stable
>>
>> Initially we did every 3 months (which arguably still aligns) then it slowly 
>> slipped to 4.
>>
>> My personal impression is that releases have gotten better as a result of 
>> those changes, so I'm hesitant about reverting that decision.
>>
>
>
> Makes sense. With Qt being less of a moving target though, it could make 
> sense to reevaluate our cadence though, both because we might start looking 
> into the future and because the system we support should not be changing as 
> much.
>

If we don't want to move to 6 months, pulling back from 4 months to 3
months would make it easier for us to not miss Plasma releases.

That being said, with Qt6 now being a thing, wouldn't that mean Qt is
more of a moving target again?



-- 
真実はいつも一つ！/ Always, there's only one truth!

Re: Distro integration for Plasma Browser Integration (was: Re: Plasma Browser Integration is in kdereview

2017-06-06 Thread Neal Gompa 
On Mon, Jun 5, 2017 at 11:22 AM, Martin Steigerwald  wrote:
> Hello David.
>
> Thanks for your effort on plasma browser integration.
>
>
> What options are possible to distribute extensions via distro packaging?
>
> I ask cause I think at least for chrome / chromium you need a Google account
> to use the plugin / extension store. Also it would put the extension outside
> of distro security support. Therefore I mostly use xul-ext packages in Debian
> as extensions for Firefox and also a new uBlock origin extension package for
> chromium.
>
> Eventually this would need to be brought up with browser developers. I am
> willing to help there by creating wishlist item / bug report.
>

In Fedora, we have actually packaged an extension for Chrome[1], so it
is possible to package Chrome extensions and have them work with
Chromium / Chrome.

If they are locally installed, Chrome will activate them, and if they
require special permissions, the user will be prompted to grant them.

[1]: 
https://src.fedoraproject.org/cgit/rpms/fedora-user-agent-chrome.git/tree/fedora-user-agent-chrome.spec


-- 
真実はいつも一つ！/ Always, there's only one truth!