I would like to have access to the Windows Store, to be able to see crashes from KDE Connect (I've been told there are lots of them) and submit releases there.

They'll be available once the instance is open for testing.

How can I get an invite?

This has essentially been completed, with the remainder relocated to https://discuss.kde.org/t/things-to-get-sorted-before-inviting-the-community-for-testing/18 so we'll track it there now.

In T11808#283949, @ognarb wrote:

An appimage can surely be added. Just need to add an artifact to the release section: https://invent.kde.org/graphics/krita/-/blob/master/krita/org.kde.krita.appdata.xml#L604

In T11675#283954, @sitter wrote:

We are now planning to move ahead with the setup of a discourse test instance so we can get a sense of how it would work in practice and what, if any, pain points we will hit. Hopefully starting this weekend.

We are now planning to move ahead with the setup of a discourse test instance so we can get a sense of how it would work in practice and what, if any, pain points we will hit. Hopefully starting this weekend.

An appimage can surely be added. Just need to add an artifact to the release section: https://invent.kde.org/graphics/krita/-/blob/master/krita/org.kde.krita.appdata.xml#L604

Krita has an AppImage but it isn't listed on https://apps.kde.org/krita, so that could be feasible with the correct metadata being defined in AppData files.

Does this add possibility for other Linux download links too? Like AppImage url? Per distribution .deb, .rpm, .pkg.tar.*, ... ?

I added a new comment to the flarum evaluation: https://invent.kde.org/sysadmin/task-queue/-/issues/31#note_561132 Personally I think discourse is the best and more mature solution and like Sitter I would also be willing to help with the deployment and maintenance of this new service.

I don't see how it's my job to disproof a proposal I am backing. The discourse eval is linked in the description of this ticket. Carl did some evaluation of other software, and from where I am standing discourse comes out ahead there as well. And then the requirement list wasn't even complete - we ultimately want to have mailing lists move into a forum (or somehow get deprecated in favor of it), discourse is the only thing properly supporting that. Krita already uses discourse successfully. So does Ubuntu, Fedora, Gitlab, GNOME... Let's not make this more complicated than it is.

I agree that there is overwhelming desire to use Discourse.

We had the discussion at Akademy in 2019 and reviewed various alternatives and decided on Discourse which is why this request was filed. It's not hard to do and there's plenty of people willing to do the work. But yeah plenty of people like to joke about it being an example of a solution we all agree on which just doesn't happen.

This late into the discussion of getting a new forum that seems like a pointless delay. There is overwhelming desire to use discourse in the community already, and it is the go-to solution in comparable large communities. And it's not like reviews save us from going down the wrong route (phabricator ;);))

Nate raised a similar query somewhat recently.

Can we select a server and start setting up new.forum.kde.org? It's quite clear that things aren't going to change and people keep asking for discourse. It's starting to be a running gag that we can't have nice things, and I'd prefer it not to be.

This has been effectively done for Discover 5.27! See https://invent.kde.org/plasma/discover/-/merge_requests/398.

I don't think volunteers can fix this problem. However, volunteers might be able to understand that there is a problem.

In T12308#278016, @vkhatab wrote:

For the love of god people
[...]
sorry if this sounds hostile - as a dedicated KDE user I mean well

Dolphin still doesn't look anything like this and even that cyan border is still there. While I understand the need to redesign a major app, all the other QT apps look just as bad or worse. A lot of this is down to the theme engine. There's been some kind of theme change recently but it hasn't made anything better - arguably worse by blending in the titlebar with the window chrome without making the whitespace in the chrome actually act like a titlebar. For the love of god people, please take the well thought out platforms as your point of reference - Windows 95, Mac OS, even Gnome ... anything. (sorry if this sounds hostile - as a dedicated KDE user I mean well).

Yeah, I think so!

Should we add these pieces of info into the same section where we are now showing links to Windows versions? With some text modification, of course, so that it doesn't mention only Windows ones?

Not only AppStream download button but other ones have all been redesigned to be visually uniform, less redundant, more familiar to users, and support l10n better, with this MR. You can see the discussion related to the MR here.

Update: all, except the archiving step, are done for games.k.o:

• "How to play" sections are shown for games having the data. These sections can also be translated;
• Accessing games.k.o pages will redirect to corresponding parts on apps.k.o, except games.k.o/old and its subpages which are left untouched.

In T10827#271310, @felixernst wrote:

I haven't done a lot of webpage work but from what I can tell this seems like a solid plan.

How do you think?

So as I can see, the 3 websites that are equivalent to categories of our apps, edu.k.o, multimedia.k.o, and utils.k.o, are still alive and really outdated, even though we already have some other plans for them. The other category-equivalent one, games.k.o, although has been ported to Jekyll, I think can still be improved.

This is more or less done, so I'm moving it to the "Done" column until we are sure everything has been wrapped up.

For appimage: I would rather prefer if e.g. Craft would produce these (as it already does) and the stuff for that stays in the craft blueprints.

To change the culture of KDE to take control of shipping out apps into stores we need to integrate app store packaging with app repos and release tools.

The release tools need to bump up the version numbers same as they do for appstream and cmake files.

I agree with the overall goal, some details follow.

ping @vpinon

Yes, the binary factory already outputs them, for sure on should aim to improve that method.

Craft is also able to create AppImage, probably the best since it allows to put all the dependencies requirements in one place.

kdenlive also has a good appimage

Some bits to get started:

Announce is being worked on in this branch https://invent.kde.org/websites/kde-org/-/merge_requests/85/diffs

Yes, our awkward playlist support is simply a bug (or more precisely, the lack of a feature). It's not an intentional design choice. See https://bugs.kde.org/show_bug.cgi?id=406477

Hey, not sure if this would be the right place to say this, just my 0.02$ of feedback on the playlist stuff. Most people I know listen to music through playlists, with most of my friends having around 5 of them. One of the things I miss from other music players is having such playlists readily available on the side bar, such as in rhythmbox, spotify, itunes, etc. I'm not sure how the playlist sidebar came to be, as I can't see it in the mockups, but it seems to assume that when a user wants to listen to a playlist they will load it from a playlist file and into the queue. In my eyes, this has a few implications when it comes to user experience:

1. It has a steep learning curve: it takes a bit of time to wrap your head around the logic of loading playlists instead of playing them. Loading files is also not a very user-friendly way of listening to a playlist.
2. It mixes the concept of queue and playlist: while it's an interesting idea, the two concepts aren't totally compatible. Let's say, for example, that I have loaded a playlist to the queue and i have made some modifications to the queue (let's say that i have removed some songs that I wasn't in the mood for). Now imagine that i wanted to add a song to one of my playlists: because the queue is where you edit the playlists, I would have to clear everything in that queue, load the fresh playlist, add the song, save the playlist and then remake the queue that I made earlier. As you can see, it interrupts playback and can be confusing if you don't understand the logic behind it.
3. It clutters the UI: while it is normal for professional software to use multiple panels to give access to more functionality at once, in my opinion a music player doesn't have to cater to the power-users, instead aiming to be as intuitive and simple to use as possible. Unless you make playlists for a living, I'm sure that most users would rather have ease of use than direct access to all of the features.

Therefore, I propose that playlist list be implemented in the left sidebar, for quick access. I see that a lot of people here are very fond of the playlist sidebar, but listing the playlists on the side would make it a less essential part of the UI and it could be moved to an entry on the left sidebar, like rhythmbox does. This way we could keep the same flexibility when editing the queue, with the only inconvenience being that it wouldn't be always visible.

I've scheduled in the first quarterly app update article here https://phabricator.kde.org/E754

Regarding the timing/diminishing-returns issue (as I agree with ltoscano that its separate from naming)... I feel it's a 2-step decision-tree here:

A challenge I think I'm seeing coming up with a good name is that... KDE sounds really, *really* *cool* already. Like, more than three letters have any right to be.

How about "KDE Drop" for quadmonthly update?

e-mail send to kde-community

It's quite ad hoc but it seems to work well on an effort-to-reward ratio as I do see people posting these bugfix announcements on social media.

We do bugfix announcements for Plasma, but they are very small and low effort, with typically three prominent bugfixes selected on the day of the announcement by Jon yelling "hey who knows what cool things were fixed recently?" in the plasma chatroom. It's quite ad hoc but it seems to work well on an effort-to-reward ratio as I do see people posting these bugfix announcements on social media.

In T14091#249489, @jriddell wrote:

One thing to tidy up then is how should bugfix releases be announced? An e-mail to kde-announce yes and an info page like https://kde.org/info/releases-20.12.2/ but should there be anything at all at https://kde.org/announcements/ and on the front page or just nothing at all?

One thing to tidy up then is how should bugfix releases be announced? An e-mail to kde-announce yes and an info page like https://kde.org/info/releases-20.12.2/ but should there be anything at all at https://kde.org/announcements/ and on the front page or just nothing at all?

To coincide with the next major version of the release service, on April, 22nd?
https://community.kde.org/Schedules/release_service/21.04_Release_Schedule#Thursday.2C_April_22.2C_2021:_21.04_Release

What would the new calendar look like? When would the next announcement be made?

"KDE Gear" is a great name

I like KDE Gear, and it also fits the KDE logo :)

I can live with "KDE Gear", but I could even live with other generic names like "KDE Bundle" or such ;)

Cool. How do people feel about "KDE Gear" as a name? I believe Albert suggested this earlier and I quite like it. It's short and has no intrinsic meaning or connection to our apps, but "gear" has an implicit meaning of "equipment; useful stuff" which I think is appropriate.

In T14091#249349, @ngraham wrote:

Regardless of what name we choose, it seems like option 1 is the preference. Shall we commit to that now?

Regardless of what name we choose, it seems like option 1 is the preference. Shall we commit to that now?

Although I like them for other reasons, I think all names that contain the word "app" or "applications" in them would not qualify. This discussion was had elsewhere and it was pointed out to me that the release did not only contain applications, making the name misleading. If you make it "applications [or apps], libraries and frameworks", which is more accurate, then it is too long.

Here's 2 cents from a quiet observer:

I think Nate's proposal is sensible. +1

In T14091#249282, @jriddell wrote:

+1 to @ngraham's proposals.

I prefer 1 as I think it's easier to understand for casual readers having a branded release announce and the wrap ups have some value but as a separate story. But 2 can work as well.

+1 to @ngraham's proposals.

Sure, yeah. So regarding the name, I see two feasible paths forward: