Debrand KDE Applications as Release Service
Open, Needs TriagePublic

Description

Following lots of chats there's some cohesion around the idea of rebranding or debranding KDE Applications as the release service.

Work out what needs to change and how the announcements will work

TODO:

jriddell created this task.Oct 29 2019, 4:07 PM
jriddell added a project: KDE Promo.
arojas added a subscriber: arojas.Oct 29 2019, 4:17 PM
ognarb added a subscriber: ognarb.Oct 29 2019, 11:50 PM
aacid added a subscriber: aacid.Oct 30 2019, 9:27 PM

We need a new branch naming scheme, i.e right now we have

Applications/19.04
Applications/19.08
etc

do we simply drop the Applications/ part ?

aacid added a comment.Oct 30 2019, 9:28 PM

We need to figure out how to name this page
https://kde.org/info/applications-19.08.0.php

aacid added a comment.Oct 30 2019, 9:30 PM

We need to finally update/kill https://community.kde.org/Release_Team too i guess

I think it would make sense for the branches to have some XXX/ namespacing.
Why not just "release/19.12" like e.g. llvm does handle that?

aacid added a comment.Oct 30 2019, 9:41 PM

I do agree i quite like the XXX/ namespacing, but i'm not sure if it's just because what i'm used to.

release/ feels a bit confusing to me, feels more like a place where only the release team commits to fix "release" issues.

What about stable/ ? Nah not good either because it's not really 18.08 is not "stable" anymore, or maybe it is?

Or perhaps version/19.04?

totte added a subscriber: totte.Nov 2 2019, 12:50 PM

+1 for "release/19.12". IMHO it makes clear that everything committed to that branch is going into the 19.12 release.

One question is what should happen with the release announcement. My thinking is that it should just be a minimal announce on kde.org/announcements similar to the bugfix ones currently for KDE Applications. The main text should be a monthly Apps Update story on the Dot like we started this month https://dot.kde.org/2019/10/07/kde-all-about-apps-october-update

ognarb added a comment.Nov 3 2019, 6:56 PM

@jriddell I don't see any advantage of using dot.kde.org instead of kde.org/announcements for this, other than the fact that the dot support RSS.

If we move the announcements to the dot we are losing i18n/l10n on the announcements and readability on the phone.

jriddell added a subscriber: sitter.Nov 4 2019, 7:07 PM

It was one of the main features of the debranding idea that @sitter came up with was to have a monthly release announce and align the release service releases with it so to debrand that service and mix in the announcements coming from that service with all the self-released apps. Having a long written announcement on kde.org just duplicates work.

I figure we want maximum exposure for this. So, much like we do with Plasma already I would suggest that we post the announcement on kde.org AND copy it to the dot.

Unlike kde.org the dot does have a feed and is being aggregated by planetkde.org.

Right now we'll get the biggest reach if we have stuff on both. Longer term it may make sense to just have announcements from kde.org aggregated on the planet, but I suppose that needs somewhat better feed support than we currently have (i.e. first we need a CMS of some sort).

Advantage of kde.org: more official looking, translateable

Advantages of dot.kde.org: gets on Planet so more readers probably

Disadvantage of kde.org: to be translated needs to be ready several days in advance which isn't very do-able and the translations needs horrible <?php i18n(" ");?> nonsense on top of the HTML which wastes a lot of time and most people aren't able to do it.

Is it really related to "debranding" though? Sounds like a separate issue that equally affects Plasma, for instance.

Disadvantage of kde.org: to be translated needs to be ready several days in advance which isn't very do-able and the translations needs horrible <?php i18n(" ");?> nonsense on top of the HTML which wastes a lot of time and most people aren't able to do it.

I'm not saying Dot is bad, it's just that it is not where I'd expect to see the official announcements go. Maybe the whole "Dot KDE, KDE Dot, dot . [dot] kde, KDE.news |", KDE4 favicon, "Download KDE" mixed image contributes to that. Maybe it's that we don't need 4 separate news feeds and it only breeds confusion? (k.o, dot.k.o, blogs.k.o, planet.k.o)
If we think that we're tired of PHP macros and really need to use Drupal instead, is that a kde.org vs dot.kde.org issue? Maybe it's about the tech that is used for each site? If so, shouldn't we just drop kde.org's separate feed then and have all official content come from Dot, which is then relocated to kde.org/news?

most people aren't able to do it.

Pardon my ignorance, but I'm not aware of anyone who's able to do Dot translations, and I see a whole list of teams that can translate kde.org announcements. If Dot is to be used, then all these people need to get access to Dot translation, just as they have to our main site now. Otherwise, this just sets an additional privilege barrier for something that is neither easy nor enjoyable already. This requires some extra time since the new workflows have to be learned and documented. Besides,

to be translated needs to be ready several days in advance

isn't going anywhere, as translators remain people and still require time to get their content made before the release.

So if Dot is to be used for anything as important as release announcements, it needs to get

  • translation access and workflow documentation resolved
  • page design and links updated
  • [likely] name and location changed

And this seems to also require deprecation of blogs.kde.org in favor of Planet, to have 2 locations instead of 4, as currently external writers seem to mostly read 1 (kde.org) and we can't expect them to do more and search for the text that is important for them across all the sister websites that we have.

TL;DR Overall, considering the current state of dot.kde.org, I am skeptical about it being ready as our announcement platform for the Applications void 19.12 announcement.

ngraham added a subscriber: ngraham.Thu, Nov 7, 1:52 PM

I agree that kde.org vs dot.kde.org seems like an orthogonal discussion. I also agree that in general it would be good to consolidate our messaging platforms, and that "dot dot K D E dot org" is a super awkward one.

I agree that kde.org vs dot.kde.org seems like an orthogonal discussion. I also agree that in general it would be good to consolidate our messaging platforms, and that "dot dot K D E dot org" is a super awkward one.

It's directly related because we need to work out how to do the Apps Update announce next month

Is it really related to "debranding" though? Sounds like a separate issue that equally affects Plasma, for instance.

Yes because we need to work out what to publish for the release next month

most people aren't able to do it.

Pardon my ignorance, but I'm not aware of anyone who's able to do Dot translations

I mean most people aren't able to write the horrible PHP/HTML mix of markup needed for the announcements on kde.org. It's a significant time waster.

Is it really related to "debranding" though? Sounds like a separate issue that equally affects Plasma, for instance.

Yes because we need to work out what to publish for the release next month

most people aren't able to do it.

Pardon my ignorance, but I'm not aware of anyone who's able to do Dot translations

I mean most people aren't able to write the horrible PHP/HTML mix of markup needed for the announcements on kde.org. It's a significant time waster.

True enough.

ognarb added a comment.Thu, Nov 7, 5:50 PM

Let's make this month applications announcement in the dot. But I still think it's an issue we need to fix in the future. I created T11986

Thank you, Carl!

Let's make this month applications announcement in the dot.

My concern is that, once we do an announcement on the Dot, the translation feature just gets dropped and no one ever gets to fixing it.

It's directly related because we need to work out how to do the Apps Update announce next month

It seems to not affect this task in any way if the announcement just happens on kde.org as before, and following announcements transition to Dot together with that of Plasma when the Dot is actually ready.

On branch naming:

"release/19.12" is not so good because such branch corresponds to multiple releases: 19.11.70 through 19.12.5.
"stable/19.12" or "development/19.12" look better to me.

Questions for the "visionaries" of the change:

Does the future "release service" provide Beta and RC (Release Candidate) releases? If yes, will they be announced somehow at kde.org or dot.kde.org? How soon they will be announced after publishing beta/RC tarballs? (this last one is more of a cue than question)

What is the process to get a new release of your application mentioned in the next monthly announcement?

What applications are eligible for being mentioned in such announcement? Are software libraries OK? Are mobile apps OK? Is server-side software OK? Should Plasma be mentioned?

aacid added a comment.Sat, Nov 9, 11:43 PM

too late for branch naming, i already went with release/19.12

aacid added a comment.Sat, Nov 9, 11:47 PM

Does the future "release service" provide Beta and RC (Release Candidate) releases?

Yes

aacid added a comment.Sat, Nov 9, 11:51 PM

too late for branch naming, i already went with release/19.12

Of course if there's an overwhelming majority of people that doesn't like it we can change the name to something else in 20.04

We also need to decide what to rename KDE_APPLICATIONS_VERSION_XXX in CMakeLists.txt if at all, or just pretend this is internal and noone cares

Keeping list of what needs to be done in phabricator is not really easy, am i doing this wrong?

Note that since the Beta for 19.12 is scheduled in 4 days i will probably just call everything KDE Applications because i don't think my questions will be answered by then

aspotashev added a comment.EditedSun, Nov 10, 12:28 AM

Keeping list of what needs to be done in phabricator is not really easy, am i doing this wrong?

You can edit this task's description and add a list of checkboxes in there.

From https://secure.phabricator.com/book/phabricator/article/remarkup/:

You can add checkboxes to items by prefacing them with [ ] or [X], like this:

  • Preheat oven to 450 degrees.
  • Zest 35 lemons.
cfeck added a subscriber: cfeck.Sun, Nov 10, 4:36 AM

We also need to decide what to rename KDE_APPLICATIONS_VERSION_XXX in CMakeLists.txt if at all, or just pretend this is internal and noone cares

KDE_RELEASE_SERVICE_XXX ?

We do need to rename it imho, otherwise it will only make things confusing. Would it be possible to do a mass renaming using the very same script that bumps the version numbers?

The only problem I can see is if someone hardcoded KDE_APPLICATIONS_VERSION in the source code instead of using ecm_setup_version, but I can volunteer to fix those apps (if any).

On branch naming:

"release/19.12" is not so good because such branch corresponds to multiple releases: 19.11.70 through 19.12.5.
"stable/19.12" or "development/19.12" look better to me.

I don't see the problem honestly, imho it's clear that the 19.12.x bugfix release comes from the 19.12 release branch.

Questions for the "visionaries" of the change:

What is the process to get a new release of your application mentioned in the next monthly announcement?

You are supposed to help write the accouncement to make sure the app you care about gets mentioned.

What applications are eligible for being mentioned in such announcement? Are software libraries OK? Are mobile apps OK? Is server-side software OK? Should Plasma be mentioned?

I don't think there is such a whitelist, but I suppose the change needs to be somehow noteworthy. I'm not sure about Plasma, I guess they will keep doing their own announcements.

cgiboudeaux updated the task description. (Show Details)Tue, Nov 12, 10:59 AM
jriddell updated the task description. (Show Details)Tue, Nov 12, 12:37 PM
jriddell updated the task description. (Show Details)Tue, Nov 12, 12:40 PM

How about https://community.kde.org/19.12_Release_Notes or https://community.kde.org/Releases/19.12_Release_Notes. I think I prefer the first

How about https://kde.org/info/releases-19.08.0.php

We'd like this to have the option for individual app changelogs only e.g. https://kde.org/announcements/releases-changelog.php?version=19.08.0 listing them all with links to
https://kde.org/announcements/releases-changelog.php?version=19.08.0&app=okular with the okular changelog

[]Update / kill https://community.kde.org/Release_Team

wipe it!

[]New name for KDE_APPLICATIONS_VERSION_XXX in CMakeLists.txt files

discussed elsewhere, I like KDE_RELEASE_SERVICE_VERSION_XXX

[]New process for .0 and bugfix release announcements which become the KDE Apps Update

This should now be the monthly KDE Apps Update stories, written a few days in advance for translations and published after the tars are released at kde.org/announcements/releases-19.12.0.php

[]Rewrite and simplify the beta and RC release announcements

Just some simple factual links

[]New name for https://kde.org/announcements/announce-applications-19.08-rc.php

How about https://kde.org/announcements/releases-19.08-rc.php

jriddell updated the task description. (Show Details)Tue, Nov 12, 1:05 PM

I prefer the second. Then https://community.kde.org/Releases can contain an index to the sub-pages

+1

[]Update / kill https://community.kde.org/Release_Team

wipe it!

+1 if an actualized module coordinators page exists / is created.

[]New name for https://kde.org/announcements/announce-applications-19.08-rc.php

How about https://kde.org/announcements/releases-19.08-rc.php

+1 simple and explicit

I prefer https://kde.org/info/releases/19.08.0 or https://kde.org/releases/19.08.0/info

It would be nice to have this integrated somehow with kde.org/applications. ;)

I would go with something like:

https://kde.org/announcements/releases/19.08.0/changelog

and

https://kde.org/announcements/releases/19.08.0/changelog/kate or using the AppStream id https://kde.org/announcements/releases/19.08.0/changelog/org.kde.kate

[]New name for https://kde.org/announcements/announce-applications-19.08-rc.php

How about https://kde.org/announcements/releases-19.08-rc.php

Following the naming scheme of the other proposed page:

I would go with: https://kde.org/announcements/releases/19.08-rc

I would quite appreciate if the change to the release service could allow us to use more hierarchical urls ;)

From discussions with Albert my current plan is to scrap the final announce for KDE Applications / Release Service and instead have the monthly apps update story on kde.org/announcements and copies onto kde.org. I'm pondering if it can be written in YAML or similar with the PHP/HTML nonsense generated from that

That would seem to subsume the apps announcements into the All About The Apps initiative. What happens once that initiative ends? You'll be stuck doing blog posts forever, that's what! This is sort of the situation I'm in with my U&P posts that became a generic commit digest type of thing.

But we have been discussing about the naming and scope of the Applications releases way before the All About The Apps initiative. I think that @jriddell mentioned that it's consistent with the All About The Apps initiative, but at least I see the two changes unrelated to each other. Not sure what the others think about this.

ognarb added a comment.EditedThu, Nov 14, 3:09 PM

From discussions with Albert my current plan is to scrap the final announce for KDE Applications / Release Service and instead have the monthly apps update story on kde.org/announcements and copies onto kde.org. I'm pondering if it can be written in YAML or similar with the PHP/HTML nonsense generated from that

If peoples are interested I could use the same system as in kate-editor.org to create announcement in yaml and markdown (and translatable). This would require to have the announcement in kde.org/announcements/release so that I don't need to care about converting all the older announcment now and just need to convert one or two announcements.

That would seem to subsume the apps announcements into the All About The Apps initiative. What happens once that initiative ends? You'll be stuck doing blog posts forever, that's what! This is sort of the situation I'm in with my U&P posts that became a generic commit digest type of thing.

The monthly app updates shouldn't just be me writing them. The idea for writing them came out of the idea for debranding KDE Applications. It's no different to who writes the KDE Applications announcements currently.

aacid added a comment.Fri, Nov 15, 9:32 AM

One thing more i forgot is https://download.kde.org/stable/applications/ needs to be somewhere else probably?

aacid updated the task description. (Show Details)Fri, Nov 15, 9:32 AM

Just to note that we didn't have an info/announcement page for the 19.12 Beta because i didn't know what to do, and it's probably going to be the same for the RC this friday.

Right. Unless someone informs me what text I should use, I will use the current templates that are at /www/announcements/announce-applications-YY.MM*php.

For the RC use this page
https://www-staging.kde.org/announcements/releases/19.12-rc/?letmein=1
which will be published at
https://kde.org/announcements/releases/19.12-rc
and can be edited at
https://invent.kde.org/websites/kde-org-announcements-releases/
the date at the top of the .md file decides whether it's published on www.kde.org or not.

For the final one I have
https://www-staging.kde.org/announcements/releases/2019-12-apps-update/?letmein=1
which will be fleshed out

release notes at
https://community.kde.org/Releases/19.12_Release_Notes

I've updated the schedule wiki page

and removed the release team wiki page

Unless Carl comes up with a better scheme just keep the info/ pages the same but rename to release-service-19.12.0.php

Changelog just keep it simple with this
https://kde.org/announcements/changelog-releases.php?version=19.12.0
which includes fulllog_release-service-$version.inc

And update kde.org and kde.org/announcements/ as normal

aacid added a comment.Wed, Nov 27, 9:32 PM

and removed the release team wiki page

I honestly think that was a bit too on the "brutal" side as a solution, but ok, i'm not in the caring too much side lately

cgiboudeaux updated the task description. (Show Details)Fri, Nov 29, 9:12 AM
cgiboudeaux updated the task description. (Show Details)Fri, Nov 29, 9:16 AM

I think the removal of https://community.kde.org/Release_Team is a mistake. In fact there is an active release-team@ list, and it is worth having a page which describes it. It should be updated instead.

cfeck added a comment.Mon, Dec 2, 9:44 PM

What does KDE release? I couldn't come up with a headline for the kde.org page, that's why it still reads "KDE Applications". We not only need an announcement text, but also new text for the kde.org main page, text for the announcement mailing list, etc.

"19.12 Releases" would do it

I think the removal of https://community.kde.org/Release_Team is a mistake. In fact there is an active release-team@ list, and it is worth having a page which describes it. It should be updated instead.

make a replacement if you like but it would just be a description and pointer to the mailing list

How about this for renaming the variable in Cmake?
https://phabricator.kde.org/D25769

How about this for renaming the variable in Cmake?
https://phabricator.kde.org/D25769

There's a nicer way: set the version on the project line and remove these lines. See https://cmake.org/cmake/help/latest/variable/PROJECT_VERSION.html (needs CMake >= 3.0)

aacid added a comment.Thu, Dec 5, 7:55 PM

No, because that forces you to use all the version, so you can't do stuff like okular or khelpcenter do