I am sure the team has already a superb workflow, and I still like to share some article, that I stumbled upon a second ago:
I imagine, this could be a good way, to provide a stable experience for people, that allows for occasional, smooth testing as well.
We could deliver a standard KDE setup, and then a second one, with all the Plasma 6 packages.
This way, testing could be as easy as switching between Wayland and X11 now.
I guess this would attract more testers, and that is surely something useful, with the upcoming releases.
Does the team already use this or a similar process?
The Garuda KDE team consists of a maximum of 2 people, to my knowledge they have nothing to do with the development of Plasma 6.
The Garuda developers/maintainers use existing resources and design and build the respective desktop interfaces and complement them with user-friendly Garuda tools.
So they are mainly busy fixing current Garuda problems.
That is why the Zen kernel is currently used, as well as X11, because it runs on the mass of devices. More testers will ensure that this is possible on any hardware combination that is not available to us as a small team.
Maybe you confuse Garuda with KDE e.V. , with countless developers
If, we need Garuda testers, but none for future changes to KDE or Gnome.
Where testing mainly consists of whether the live ISO boots and installs with calamares error free on metal.
The distro from where I came from, consists of a single maintainer - and that did build the whole distro from scratch, supported everything, created the ISO, and tested.
I am used to testing new ISOs, future updates, and everything attached to it.
So I donāt think that this needs to be limited to the distro maintainers.
We have a community of enthusiastic people, and if they like to contribute, be it the Garuda-specific stuff, or Plasma itself, then I donāt see a reason why we should prevent it.
I guess this could differentiate us from the distros who are known for ājust changing a few irrelevant aspects, such as the wallpaperā, and would certainly be appreciated by the Arch community.
And this way or the other way: The change to Plasma 6 will come with a lot of hurdles, and we cannot expect them to be entirely resolved by Arch.
Specific settings, configuration files, and stuff like this could need a port, and some of them are surely custom to us.
I think you already realize that we are different from those, otherwise you would just use pure KDE.
Garuda Linux was developed because developers of another distribution asked us to do so, not to be appreciated by the Arch community. We wanted to implement our ideas and then made them available to the public.
That was it.
Again, Garuda Linux consists of more than the KDE DE.
If you want to be useful, test the other DEās as well.
This article discusses an alternative method for compiling Plasma from source, so for example a new patch or change in the code could be tested. It would be specifically relevant for KDE developers. Garuda Linux does not compile a custom version of Plasma, nor even package Plasma for that matter (we use the KDE packages that Arch provides), so this kind of tooling would not really be useful here.
The article is also from four years agoāwell out of date. The instructions for compiling Plasma 6 from source are here: Get Involved/development/More - KDE Community Wiki. I do not see that script mentioned anywhere in the documentation; I think it is safe to assume it is defunct.
If anyone wants to test Plasma 6, these are the options available:
Developers and adventurous users are encouraged to test or even live on Plasma 6, to help get it into a releasable state faster. Before doing so, remember the rules of Plasma 6:
Read through the list of major bugs and only use Plasma 6 in production if none of them is a deal-breaker for you. Maintain regular backups! This is mandatory.
When you encounter an issue in Plasma 6 that was not present in Plasma 5, check the list of issues to see if itās already been reported. If you donāt find anything, submit a bug report and add the āqt6ā keyword to it.
If you are technically able, try to fix issues you encounter yourself.
Options for testing Plasma 6 include the following:
I think it is good for the community to get involved with testing, and I encourage people to do that as long as they are willing to follow through with reporting issues in the proper channels.
What we do not want is for people to try Plasma 6 (or Gnome 45, or whatever) and report in the Garuda Linux forum āI tried Plasma 6 and [insert random KDE thing] is broken.ā The issues donāt get visibility with the developers, nothing gets fixed, and the users and forum helpers all get frustrated. We have very few forum helpers as it is; taking on bug triage for a major DEās beta release is way beyond the scope of what is realistic for our forum.
As far as I know, are there Plasma 6 packages built into chaotic, @alexjp is reportedly doing so.
Nobody said this. I suggested we try the upcoming major release of our major DE, and not that we spam the forum with user reports about it.
It should be clear, that we report that to KDE directly.
Well, to be honest: I am not surprised by this. Making testing easily accessible, and encouraging people to do so is certainly not yet something I have seen here a lot.
I suggested several different methods that would lower the barrier of testing, so more people can feel confident (and not annoyed) by the process.
It was not even a public matter to test the upcoming ISOs for some reason, and making testing more accessible, even seems to be outright rejected as an idea, at times.
The more experienced developers might not need this, but the less involved definitely benefit from some conscious introduction.
They might not be as confident, and simply overestimate the involved complexity, and offering a streamlined, simple approach, is probably motiving a lot of them.
Can more people become involved, when we subconsciously gatekeep themā¦?
Im going to weigh in here. I HATE the idea of a hybrid ISO where apon install one can switch between Plasma versions. I can see a complete and utter DISASTER live the ones that can happen when one installs more than one DE.
If you donāt agree with what Garuda offers, you should get involved with KDE directly. That would certainly make more sense.
Thatās the way of life, by the way, Garuda was created on that basis.
āWhy donāt you make your own distribution if youāre not happy with oursā.
I just see a couple of things, that could be improved.
Among them, would be that people would start to read and understand before they respond.
It has happened a couple of times now, that the initial post got sidelined, and people assumed they knew what was the intention behind it, and even declared solutions to it, who were clearly missing the point.
Garuda is one of the most prominent distros, at least when we can trust the almighty distrowatch.com
So does this popularity lead to an increase in contributors?
No? Then I would ask myself why.
It could be because Garuda takes a lot of care about the user experience and maybe less about onboarding new members as contributors.
This post has asked to understand if we could adopt a way to test, that does not involve permanently altering someoneās desktop.
I understand the approach that has been given, and just like with the ISOs and other testing methodologies does this one assume, that someone who is willing to contribute is also willing to do a lot more work as it is actually needed.
And also more as some people are capable and willing to do.
So if we make contributing easier, will it surely lead to more contributions.
If this discussion does not address your intended point, then the issue is your point has not been clearly announced. I think with a title like āStrategy to test Plasma 6ā, it is reasonable to infer that you wish to test Plasma 6. Now you are making it sound like something else is the goal, and Plasma 6 has nothing to do with it.
This can easily be achieved by adding testing installations in separate subvolumes.
I do this all the time, it is very simple and allows an installation to be added to the disk without touching the existing installations in any way. Sometimes I do four or five installations in a day for testing, then just delete the subvolumes when Iām done and itās like they were never there.
At this point I have a repo in GitLab I pull down on the fresh installation, with a script inside that automates some of the post-install chores like renaming the default subvolumes, mounting the shared resources, and setting up my config files how I like them. That way I can just run it after the installation completes and carry on without having to bother setting everything up manually.
Yes, it is great for testing. I think it has been added to a few testing announcements, although Iām not sure how many folks have actually tried it out.
The wiki post is the more digestible version of this much long winded/more elaborate post:
Itās not a new method by any means, Iāve been doing it for a while. But yes, for things like ISO testing, installing multiple desktop environments/multiple distros, pulling in a testing repo, or any kind of major tinkering where you donāt want to mess up your setup it is just great!
The text in the Wiki sounds a bit aggressively discouraging.
Will look into this in the next few days, and write a short article about how to go from zero to this.
