Re: Proposal unify back our release schedules
For the same reason they are sometimes seen as convenient this type of container format can be a pain when a security patch or bug fix needs to be propagated to every app that uses a library on an individual basis. Also some app image formats like flatpak are very restrictive by default on what they allow an app to do. Something to think about as we will get bugs related to that if app images become the primary distribution mechanism. Apr 24, 2024 1:56:30 PM Martin Flöser : > Am Freitag, 19. April 2024, 11:04:33 CEST schrieb Carl Schwan: >> Currently this is just a proposal, not a vote proposal or anything like >> that. I'll be happy to receive positive or negative feedback on this idea. > > Reading through the proposal and the discussion, I think we need to think a > little bit outside of the box. I have the feeling that most devs still see > Linux distributions as the primary way to distribute our software. I do not > think that this is universal true anymore and if we move away from it, this > would open up way new possibilities. > > Let's assume for apps we see Flathub/Snaps/Windows Store/whatever store as our > primary distribution channel, this would give us quite some advantages: > > * less duplicated work for distributions > * no problems with "this framework release is not packaged yet" > * no overwhelmed work for distributions due to too many packages need to be > updated > * no need to push an update if nothing changed > * no random "this pulls in KDE" due to incorrect packaging > * always up to date software for our users > * no bad experience due to missing (optional) dependencies > * easy release for the maintainers without needing a release team (what about > a Gitlab create release pipeline the maintainer can press) > > So this would totally open up a new way to release and distribute "Gear". And > with Gear being easily available for everyone this would also give the > possibility to move things into Plasma which belong into Plasma, but haven't > been for "this is an app and also usable on other desktop". What comes in my > mind is everything that are essential apps for a decent desktop experience: > > * dolphin > * spectacle > * an image viewer (gwenview/koko, etc.) > * okular > * ... > > Those could still be apps, but be released together with Plasma, thus also > tightly integrate with Plasma while at the same time be distributed through > other channels. > > Such a model should also help with the development experience. I read a few > comments about it being a problem on depending on frameworks master - I agree > that is a problem. But not so much if there is always an up to date > development container available to pull and hack on. If apps are > containerized, their build environment can also be containerized. > > So my suggestion: think about more than just the release cycle and the > alignment of the releases if you are going to touch this (hot) topic. > > Cheers > Martin signature.asc Description: PGP signature
Re: Proposal unify back our release schedules
Am Freitag, 19. April 2024, 11:04:33 CEST schrieb Carl Schwan: > Currently this is just a proposal, not a vote proposal or anything like > that. I'll be happy to receive positive or negative feedback on this idea. Reading through the proposal and the discussion, I think we need to think a little bit outside of the box. I have the feeling that most devs still see Linux distributions as the primary way to distribute our software. I do not think that this is universal true anymore and if we move away from it, this would open up way new possibilities. Let's assume for apps we see Flathub/Snaps/Windows Store/whatever store as our primary distribution channel, this would give us quite some advantages: * less duplicated work for distributions * no problems with "this framework release is not packaged yet" * no overwhelmed work for distributions due to too many packages need to be updated * no need to push an update if nothing changed * no random "this pulls in KDE" due to incorrect packaging * always up to date software for our users * no bad experience due to missing (optional) dependencies * easy release for the maintainers without needing a release team (what about a Gitlab create release pipeline the maintainer can press) So this would totally open up a new way to release and distribute "Gear". And with Gear being easily available for everyone this would also give the possibility to move things into Plasma which belong into Plasma, but haven't been for "this is an app and also usable on other desktop". What comes in my mind is everything that are essential apps for a decent desktop experience: * dolphin * spectacle * an image viewer (gwenview/koko, etc.) * okular * ... Those could still be apps, but be released together with Plasma, thus also tightly integrate with Plasma while at the same time be distributed through other channels. Such a model should also help with the development experience. I read a few comments about it being a problem on depending on frameworks master - I agree that is a problem. But not so much if there is always an up to date development container available to pull and hack on. If apps are containerized, their build environment can also be containerized. So my suggestion: think about more than just the release cycle and the alignment of the releases if you are going to touch this (hot) topic. Cheers Martin
Re: Proposal unify back our release schedules
On Saturday, 20 April 2024 15.50.58 CEST Kevin Ottens wrote: > One thing I'm unsure for instance is: do we want to make Gear -> Plasma > dependencies completely forbidden? > > We might consider this going one step too far. I could understand if a Gear > app wants to provide "more integration" in a Plasma session. So mandatory > Gear -> Plasma dependencies, I agree are to forbid, but optional ones? I'm > less certain. if such a ban would get in place, imposes to treat even more with care the tendency to put things in plasma instead of doing a proper framework because they are much easier to manage/depend from within plasma (still not convinced at the activities move for instance 廊) -- Marco Martin
Re: Proposal unify back our release schedules
On Friday, 19 April 2024 18.39.01 CEST Kevin Ottens wrote: > > * We end up with 3 different products which are released at different > > times > > but are connected together. Apps and Plasma both need Framework, Plasma > > needs some packages from gear like kio-extra, Gear needs some package from > > Plasma like Breeze. Coordinating all these inter-groups dependencies is > > complex and was one the reason we had to do a megarelease for Plasma 6. > > Also for the end user, one product is a lot easier to understand. > > This is an engineering topic in this case. > > And, to me, this is an excellent reason not to reunify release schedules! > Because what it tells me is that we're still having dependency issues which > need to be solved. sometimes the dependency problem i hear people comaplaining about is also more of a thing "for this app(or plasma) release i want to use this framework feature but i can't yet because i can't depend from x version" which really seems to be a problem to be solved with more... discipline? -- Marco Martin
Re: Proposal unify back our release schedules
> As a result I'll rescind my idea to slow down Frameworks feature > releases. Then I'll take over and fight for it! >that having a fast Frameworks release cycle allows > people developing apps with features in Frameworks to not have to live > on master like we do in Plasma. That was the motivation for the change. And it's simply a bad motivation. The most important stakeholder of our release cycle is not app developers. It's the end-user. We've seen this in practice over the last 10 years that the user experience suffers with the short release cycle. Less than a month is not enough for any meaningful testing, especially for API that we commit to for years and years. We've seen last minute respins and panics on so many 5.x releases.That trumps any other developer-centric argument by far as the most important thing for developers is their apps to work well with the libraries they use. I am 100% certain we would have better products with a different branch policy on frameworks than the current optimistic policy of master always being perfect and not having bugfix releases. How branch policy changes how we do releases still has many many options, but I would like to see something change and this proposal does fix that. David
Re: Proposal unify back our release schedules
On Mon, Apr 22, 2024 at 2:29 PM Nate Graham wrote: > > > > On 4/22/24 19:19, Albert Astals Cid wrote: > > El dilluns, 22 d’abril del 2024, a les 17:12:46 (CEST), Nate Graham va > > escriure: > >> Now, let's say we make Gear use Plasma's current release schedule by > >> syncing up the feature releases and adopting the Fibonacci bugfix > >> releases. If we don't end up changing Plasma's own release schedule then > >> we already make our promo store more coherent by letting the marketing > >> team do three big glossy announcements of user-facing products a year, > >> rather than being stretched thin for 6. Even if we make Plasma go down > >> to 2 releases a year, then we have two synced Gear+Plasma > >> "mega-releases" and 2 independent Gear releases--down from 6 to 4. Both > >> of these options would improve the promo story IMO. > >> > >> --- > >> > >> Moving on, the biggest points of contention I see revolve around > >> Frameworks. Personally I want to push back a bit on the idea of > >> developing an app against released frameworks. > > > > I disagree. > > > > In my ideal world, applications should be able to be built against a one > > year > > old frameworks, before the Qt6 port, Okular's minimum requirement was Ubuntu > > 22.04, which makes sure virtually everyone can contribute to it without > > having > > to build the world. > > > > There's virtually no need in Okular to depend against any new frameworks > > shiny > > feature, the existing features are more than enough. > > > > Cheers, > >Albert > > This is true for Okular, but we can't guarantee it for other apps. > > However I was fortunate enough to be sitting across a table from Volker, > who explained this point to me in a way that my tiny brain was capable > of understanding: :) that having a fast Frameworks release cycle allows > people developing apps with features in Frameworks to not have to live > on master like we do in Plasma. > > I'd love to have everywhere in my slide of KDE what Albert has for > Okular, but I there are other barriers to it that we need to overcome. > > As a result I'll rescind my idea to slow down Frameworks feature > releases. I do still think Frameworks could benefit from un-branched > bugfix releases a week after the feature releases--after which point > feature development would be open again. > > And I still support unifying or aligning the Gear and Plasma release > schedules. > Then I think we're back to my idea of monthly frameworks, quarterly Gear, and semi-annual Plasma with semi-synchronized schedules. -- 真実はいつも一つ！/ Always, there's only one truth!
Re: Proposal unify back our release schedules
On 4/22/24 19:19, Albert Astals Cid wrote: El dilluns, 22 d’abril del 2024, a les 17:12:46 (CEST), Nate Graham va escriure: Now, let's say we make Gear use Plasma's current release schedule by syncing up the feature releases and adopting the Fibonacci bugfix releases. If we don't end up changing Plasma's own release schedule then we already make our promo store more coherent by letting the marketing team do three big glossy announcements of user-facing products a year, rather than being stretched thin for 6. Even if we make Plasma go down to 2 releases a year, then we have two synced Gear+Plasma "mega-releases" and 2 independent Gear releases--down from 6 to 4. Both of these options would improve the promo story IMO. --- Moving on, the biggest points of contention I see revolve around Frameworks. Personally I want to push back a bit on the idea of developing an app against released frameworks. I disagree. In my ideal world, applications should be able to be built against a one year old frameworks, before the Qt6 port, Okular's minimum requirement was Ubuntu 22.04, which makes sure virtually everyone can contribute to it without having to build the world. There's virtually no need in Okular to depend against any new frameworks shiny feature, the existing features are more than enough. Cheers, Albert This is true for Okular, but we can't guarantee it for other apps. However I was fortunate enough to be sitting across a table from Volker, who explained this point to me in a way that my tiny brain was capable of understanding: :) that having a fast Frameworks release cycle allows people developing apps with features in Frameworks to not have to live on master like we do in Plasma. I'd love to have everywhere in my slide of KDE what Albert has for Okular, but I there are other barriers to it that we need to overcome. As a result I'll rescind my idea to slow down Frameworks feature releases. I do still think Frameworks could benefit from un-branched bugfix releases a week after the feature releases--after which point feature development would be open again. And I still support unifying or aligning the Gear and Plasma release schedules. Nate
Re: Proposal unify back our release schedules
Hello, On Monday 22 April 2024 18:08:04 CEST Carl Schwan wrote: > On Friday, April 19, 2024 6:39:01 PM GMT+2 Kevin Ottens wrote: > > Unsurprisingly I'll be pretty much aligned with Luigi, Sune and Volker > > here I think. I'll try to add a couple of extra aspects to feed the > > thinking on this topic. > > Thanks you all for raising some important points. Taking into account the > feedback, I would like to slightly change my proposal. > > - Unify only the release schedule of Gear and Plasma with a frequency of > either 4 months or 6 months. This would follow the Fibonacci release > schedule. Sounds good to me, although we probably want others to chip in. > - Keep framework release once every month. But ensure that once every 4 (or > 6) months, it happens at the same time as Gear and Plasma. We can keep the > frequent features release of framework, which seems to be valuable for > people not compiling the whole stack from source. That doesn't sound too hard to achieve. Back when releases were done by David it was tagged at a fixed predictable day of the month. It seems this is not the case anymore (although it's hard to extrapolate from two data points: 6.0 and 6.1), so should make it easier to meeting Gear and Plasma releases if it's floating a bit. If there's a will to go back to a predictable day in the month, then we might want to instead have Gear and Plasma target this. It's merely details though, a question of putting new habits in place, nothing blocking IMHO even probably the right time to do so. > For the occasion where the Framework, Gear and Plasma, we should then ensure > that the framework release is done at the same time or slightly before the > gear and plasma release and ideally there is also a special beta release of > Framework done at the same time as the gear and Plasma beta, which can be > tested together with the other beta releases. I guess it depends on how long the beta phase is for Plasma and Gear at this point. If it's around a month you might want in fact this Frameworks n-1 to be the "beta" and having the n-1 to n month to be only about bugfixes and no features. It'd make for a regular "stabilization only" KDE Frameworks release. The alternative would be to add an extra beta release in between n-1 and n. So it's a question of the release team wanting to do it or not. > If Plasma decides to switch to a release every 6 months and Gear prefers to > keep a shorter release cycle, then I would suggest using 3 months for gear > so that we still have an unified released of framework, gear and plasma > once every 6 months. I'm less fan of this and if we have a very good reason > to switch to a 6 months release cycle for Plasma, this argument should also > apply to Gear. I have no strong opinion about the 4 vs 6 months. Having the frequency of Gear allowing of an alignment with Plasma from time to time definitely makes sense. > > On Friday 19 April 2024 11:04:33 CEST Carl Schwan wrote: > > > * We end up with 3 different products which are released at different > > > times but are connected together. Apps and Plasma both need Framework, > > > Plasma needs some packages from gear like kio-extra, Gear needs some > > > package from Plasma like Breeze. Coordinating all these inter-groups > > > dependencies is complex and was one the reason we had to do a > > > megarelease for Plasma 6. Also for the end user, one product is a lot > > > easier to understand. > > > > This is an engineering topic in this case. > > > > And, to me, this is an excellent reason not to reunify release schedules! > > Because what it tells me is that we're still having dependency issues > > which need to be solved. > > > > The example you give shows Plasma depending on Gear, this shouldn't > > happen, so I'd argue: let's fix that instead. > > > > Aligning the release schedules would only hide such structural issues. > > > > This was one of the main engineering motives to split things up: when it > > wasn't splitted this would stay hidden much longer everyone being comfy > > with it. > > > > Now it's creating pain: perfect, that makes the issue obvious, but it > > should be addressed not masked. > > > > This is in part what Volker highlighted pointing out this should be less > > of a problem with key components being moved to Plasma. Again, if there > > are more, let's just address them. > > > > So as pointed out by Sune and Volker: this is a feature (at least in the > > Frameworks case) not a bug. > > I'm been working a lot on the visual of applications across the whole stack > and for me, the pain is mostly caused by the fact element of our styling are > spread across the 3 releases: gear/plasma and framework. The megarelease > has been tremendously helpful to get visual changes implemented > consistently across the entire stack and I don't think this can be solved > even with the best will. > > Plasma holds Breeze which holds information about how our controls look > like. There
Re: Proposal unify back our release schedules
El dilluns, 22 d’abril del 2024, a les 17:12:46 (CEST), Nate Graham va escriure: > Ok, so happily I actually see quite a bit of agreement here, regardless > of what else we do. > > 1. Fibonacci bugfix releases are good, and we could benefit from having > Gear adopt these. > > 2. Severing implicit dependencies is a good idea. Shared libraries in > Gear are especially problematic and could benefit from being moved to > Frameworks. > > 3. Fast frameworks releases in some capacity are a benefit and we don't > want to lose this. > > > All in agreement? If so, that would be amazing. > > --- > > Now, let's say we make Gear use Plasma's current release schedule by > syncing up the feature releases and adopting the Fibonacci bugfix > releases. If we don't end up changing Plasma's own release schedule then > we already make our promo store more coherent by letting the marketing > team do three big glossy announcements of user-facing products a year, > rather than being stretched thin for 6. Even if we make Plasma go down > to 2 releases a year, then we have two synced Gear+Plasma > "mega-releases" and 2 independent Gear releases--down from 6 to 4. Both > of these options would improve the promo story IMO. > > --- > > Moving on, the biggest points of contention I see revolve around > Frameworks. Personally I want to push back a bit on the idea of > developing an app against released frameworks. I disagree. In my ideal world, applications should be able to be built against a one year old frameworks, before the Qt6 port, Okular's minimum requirement was Ubuntu 22.04, which makes sure virtually everyone can contribute to it without having to build the world. There's virtually no need in Okular to depend against any new frameworks shiny feature, the existing features are more than enough. Cheers, Albert > This is only realistic if > you use a rolling release distro and are okay with waiting a month to > use the new Frameworks code. > > For users looking to contribute with common > discrete-release distros, it is not at all realistic as many Frameworks > consumers require versions newer than what those users have on their > system, so they have to build some Frameworks anyway (note: not all of > them; kdesrc-build/kde-builder are smart enough not to do unnecessary > work). The older the distro's packages, the more likely this is to be. > > Furthermore, because Frameworks has time-based releases and no beta > releases, in practice the QA is provided by developers living on master. > If KDE developers deliberately avoid this, they're not participating in > QA. There are of course other ways to improve Frameworks' QA as well, > but continuing to encourage KDE developers to use distro-packaged > Frameworks goes against the larger goal: we can't QA software versions > we're not using. > > While 12 releases a year of Frameworks feels fast, it's actually not. > Gear also has 12 releases a year: 3 feature releases and 9 bugfix > releases. And Plasma currently gets 18: 3 feature releases and 15 bugfix > releases. The lack of bugfix releases is notable. With Plasma if a major > bug is discovered a day after the release (which is common) I can ship a > fix within a week, whereas for Frameworks, it takes a month. This is not > a theoretical problem; it has happened many times over the years. > > To me it has always felt strange that the product that benefits most > from stability gets 4 times as many yearly feature releases as Gear and > Plasma, but no bugfix releases at all. And there have been many > occasions oven the years where new features in Frameworks could have > benefited from a bit more QA time in master before final release. > > In this sense I find Frameworks' release schedule to be both too fast > and too slow: too fast for new features and too slow for bugfixes. > Shouldn't the product with the strongest stability guarantee ship > bugfixes at least as fast as Plasma? > > If Frameworks got a feature release every 2 or 3 months and a guaranteed > bugfix release one week after each feature release, IMO the result would > be much better. We could ship fixes for important bugs faster, > developers would be more incentivized to live on master and therefore > provide their own QA, the period of time during which issues with new > features could be caught before release would be doubled or tripled, and > we could even still have 12 total releases per year. > > --- > > Thus, if we make Gear's release cycle identical to Plasma's to get it > faster bugfixes, and then we also lengthen Frameworks' release cycle so > it gets the bugfix releases it could benefit from while slowing down its > feature releases to improve QA, then the result looks a lot like Carl's > proposal, and that's ultimately why it looks appealing to me. > > This doesn't preclude breaking implicit dependencies and relocating > software into groups/release vehicles more suited for them. I don't find > the argument convincing that
Re: Proposal unify back our release schedules
On Friday, April 19, 2024 6:39:01 PM GMT+2 Kevin Ottens wrote: > Hello, > > Unsurprisingly I'll be pretty much aligned with Luigi, Sune and Volker here > I think. I'll try to add a couple of extra aspects to feed the thinking on > this topic. Thanks you all for raising some important points. Taking into account the feedback, I would like to slightly change my proposal. - Unify only the release schedule of Gear and Plasma with a frequency of either 4 months or 6 months. This would follow the Fibonacci release schedule. - Keep framework release once every month. But ensure that once every 4 (or 6) months, it happens at the same time as Gear and Plasma. We can keep the frequent features release of framework, which seems to be valuable for people not compiling the whole stack from source. For the occasion where the Framework, Gear and Plasma, we should then ensure that the framework release is done at the same time or slightly before the gear and plasma release and ideally there is also a special beta release of Framework done at the same time as the gear and Plasma beta, which can be tested together with the other beta releases. If Plasma decides to switch to a release every 6 months and Gear prefers to keep a shorter release cycle, then I would suggest using 3 months for gear so that we still have an unified released of framework, gear and plasma once every 6 months. I'm less fan of this and if we have a very good reason to switch to a 6 months release cycle for Plasma, this argument should also apply to Gear. > On Friday 19 April 2024 11:04:33 CEST Carl Schwan wrote: > > > > * We end up with 3 different products which are released at different > > times > > but are connected together. Apps and Plasma both need Framework, Plasma > > needs some packages from gear like kio-extra, Gear needs some package from > > Plasma like Breeze. Coordinating all these inter-groups dependencies is > > complex and was one the reason we had to do a megarelease for Plasma 6. > > Also for the end user, one product is a lot easier to understand. > > This is an engineering topic in this case. > > And, to me, this is an excellent reason not to reunify release schedules! > Because what it tells me is that we're still having dependency issues which > need to be solved. > > The example you give shows Plasma depending on Gear, this shouldn't happen, > so I'd argue: let's fix that instead. > > Aligning the release schedules would only hide such structural issues. > > This was one of the main engineering motives to split things up: when it > wasn't splitted this would stay hidden much longer everyone being comfy with > it. > > Now it's creating pain: perfect, that makes the issue obvious, but it should > be addressed not masked. > > This is in part what Volker highlighted pointing out this should be less of > a problem with key components being moved to Plasma. Again, if there are > more, let's just address them. > > So as pointed out by Sune and Volker: this is a feature (at least in the > Frameworks case) not a bug. I'm been working a lot on the visual of applications across the whole stack and for me, the pain is mostly caused by the fact element of our styling are spread across the 3 releases: gear/plasma and framework. The megarelease has been tremendously helpful to get visual changes implemented consistently across the entire stack and I don't think this can be solved even with the best will. Plasma holds Breeze which holds information about how our controls look like. There was discussion in the KF6 board to move breeze to be a framework but due to the license this is not possible (unless we change the definition of framework and allow GPL stuff). Framework holds qqc2-desktop-style and breeze-icons as well as a lot of custom widgets frameworks like Kirigami, KWidgetsAddons, KConfigWidgets, KItemView, KXmlGui, ... There are also a lot of libraries in gear which contains custom widgets (a lot in PIM but not only). Apps themselves also contains a lot of design elements. This includes some custom widgets but also the general layout of the app and dialogs. This could be fixed by adding a lot more widgets in apps to KWidgetsAddons/Kirigami, but it doesn't always make sense as some widgets are super niche and don't belong to a Framework/library. Some examples from the recent redesign in the megarelease are the design of periodical table cell elements in Kalzium which previously followed the Oxygen guidelines and now is more Breeze looking. Another one is the layout of the Kate search and replace dock and a lot of other docks which had to be changed to have a more "frameless" look. It won't solve the issue for extragear applications, but I don't want the search of a perfect solution for 100% of our apps prevent us to fix to improve the situation for at least a big chunk of them. Particularly since unifying the gear and plasma release, won't make the situation worse for the
Re: Proposal unify back our release schedules
Ok, so happily I actually see quite a bit of agreement here, regardless of what else we do. 1. Fibonacci bugfix releases are good, and we could benefit from having Gear adopt these. 2. Severing implicit dependencies is a good idea. Shared libraries in Gear are especially problematic and could benefit from being moved to Frameworks. 3. Fast frameworks releases in some capacity are a benefit and we don't want to lose this. All in agreement? If so, that would be amazing. --- Now, let's say we make Gear use Plasma's current release schedule by syncing up the feature releases and adopting the Fibonacci bugfix releases. If we don't end up changing Plasma's own release schedule then we already make our promo store more coherent by letting the marketing team do three big glossy announcements of user-facing products a year, rather than being stretched thin for 6. Even if we make Plasma go down to 2 releases a year, then we have two synced Gear+Plasma "mega-releases" and 2 independent Gear releases--down from 6 to 4. Both of these options would improve the promo story IMO. --- Moving on, the biggest points of contention I see revolve around Frameworks. Personally I want to push back a bit on the idea of developing an app against released frameworks. This is only realistic if you use a rolling release distro and are okay with waiting a month to use the new Frameworks code. For users looking to contribute with common discrete-release distros, it is not at all realistic as many Frameworks consumers require versions newer than what those users have on their system, so they have to build some Frameworks anyway (note: not all of them; kdesrc-build/kde-builder are smart enough not to do unnecessary work). The older the distro's packages, the more likely this is to be. Furthermore, because Frameworks has time-based releases and no beta releases, in practice the QA is provided by developers living on master. If KDE developers deliberately avoid this, they're not participating in QA. There are of course other ways to improve Frameworks' QA as well, but continuing to encourage KDE developers to use distro-packaged Frameworks goes against the larger goal: we can't QA software versions we're not using. While 12 releases a year of Frameworks feels fast, it's actually not. Gear also has 12 releases a year: 3 feature releases and 9 bugfix releases. And Plasma currently gets 18: 3 feature releases and 15 bugfix releases. The lack of bugfix releases is notable. With Plasma if a major bug is discovered a day after the release (which is common) I can ship a fix within a week, whereas for Frameworks, it takes a month. This is not a theoretical problem; it has happened many times over the years. To me it has always felt strange that the product that benefits most from stability gets 4 times as many yearly feature releases as Gear and Plasma, but no bugfix releases at all. And there have been many occasions oven the years where new features in Frameworks could have benefited from a bit more QA time in master before final release. In this sense I find Frameworks' release schedule to be both too fast and too slow: too fast for new features and too slow for bugfixes. Shouldn't the product with the strongest stability guarantee ship bugfixes at least as fast as Plasma? If Frameworks got a feature release every 2 or 3 months and a guaranteed bugfix release one week after each feature release, IMO the result would be much better. We could ship fixes for important bugs faster, developers would be more incentivized to live on master and therefore provide their own QA, the period of time during which issues with new features could be caught before release would be doubled or tripled, and we could even still have 12 total releases per year. --- Thus, if we make Gear's release cycle identical to Plasma's to get it faster bugfixes, and then we also lengthen Frameworks' release cycle so it gets the bugfix releases it could benefit from while slowing down its feature releases to improve QA, then the result looks a lot like Carl's proposal, and that's ultimately why it looks appealing to me. This doesn't preclude breaking implicit dependencies and relocating software into groups/release vehicles more suited for them. I don't find the argument convincing that we ought to deal with pain to make this happen. IMO we should make decisions about the final form we want, not based on what we think will torture us into getting there. :) Nate
Re: Proposal unify back our release schedules
>> in that event I'd like for us to put it >> to a formal KDE e.V. vote > Is this an eV topic? Yes and no. The original decision had a big impact, changing things again will have a big impact. It's not something that should be decided by a few people, nor is it something that should be decided or squashed by a "who can talk for longest" on a mailing list. Should it be discussed behind closed doors on the eV mailing list? No. Is an eV vote the only way to get something that's fair and representative and reach a binary conclusion? I can't think of anything better I think it's a resource we should use more often. David
Re: Proposal unify back our release schedules
On Sunday, 21 April 2024 00:37:03 CEST Ben Cooksley wrote: > On Sun, Apr 21, 2024 at 1:51 AM Kevin Ottens wrote: > > Hello, > > > > On Saturday 20 April 2024 15:12:48 CEST Ingo Klöcker wrote: > > > On Freitag, 19. April 2024 22:40:38 CEST Ben Cooksley wrote: > > > > On Sat, Apr 20, 2024 at 4:39 AM Kevin Ottens wrote: > > > > > The example you give shows Plasma depending on Gear, this shouldn't > > > > > happen, so > > > > > I'd argue: let's fix that instead. > > > > > > In my opinion the same goes for Gear depending on Plasma. > > > > Agreed, just didn't want to muddy my message and so focused on only one > > direction. But it's definitely a topic to explore as well. > > > > One thing I'm unsure for instance is: do we want to make Gear -> Plasma > > dependencies completely forbidden? > > > > We might consider this going one step too far. I could understand if a > > Gear > > app wants to provide "more integration" in a Plasma session. So mandatory > > Gear > > -> Plasma dependencies, I agree are to forbid, but optional ones? I'm less > > certain. > > I've considered whether it was feasible to ban such dependencies in the > past, however always ended up in the position that it wasn't feasible to do > so. > This will require a degree of projects being moved around, code being > broken out into separate modules, etc. but I think it is solvable given > enough commitment to do so. > > We probably need a home for "not quite Frameworks but shared libraries none > the less" to make this achievable. > > The usual tripping points ended up being: > - Various graphics and multimedia libraries such as libkdcraw, libkexiv2, > etc > - Various PIM libraries, often related to Akonadi integration for Workspace One approach to solve that is/was to actually turn those into frameworks. A bunch of PIM libraries were moved over time (KContacts, KCalendarCore, KDAV, etc) already. More were lined up, the KF6 transition just put a pause on that, but e.g. KMime not too long ago received a bunch of API fixes in preparation for this. However, before continuing down that road I'd like to see a decision on the KF release schedule first now. With a much longer release cycle this becomes a lot less interesting to do. Regards, Volker signature.asc Description: This is a digitally signed message part.
Re: Proposal unify back our release schedules
On Sun, Apr 21, 2024 at 1:51 AM Kevin Ottens wrote: > Hello, > > On Saturday 20 April 2024 15:12:48 CEST Ingo Klöcker wrote: > > On Freitag, 19. April 2024 22:40:38 CEST Ben Cooksley wrote: > > > On Sat, Apr 20, 2024 at 4:39 AM Kevin Ottens wrote: > > > > The example you give shows Plasma depending on Gear, this shouldn't > > > > happen, so > > > > I'd argue: let's fix that instead. > > > > In my opinion the same goes for Gear depending on Plasma. > > Agreed, just didn't want to muddy my message and so focused on only one > direction. But it's definitely a topic to explore as well. > > One thing I'm unsure for instance is: do we want to make Gear -> Plasma > dependencies completely forbidden? > > We might consider this going one step too far. I could understand if a > Gear > app wants to provide "more integration" in a Plasma session. So mandatory > Gear > -> Plasma dependencies, I agree are to forbid, but optional ones? I'm less > certain. > I've considered whether it was feasible to ban such dependencies in the past, however always ended up in the position that it wasn't feasible to do so. This will require a degree of projects being moved around, code being broken out into separate modules, etc. but I think it is solvable given enough commitment to do so. We probably need a home for "not quite Frameworks but shared libraries none the less" to make this achievable. The usual tripping points ended up being: - Various graphics and multimedia libraries such as libkdcraw, libkexiv2, etc - Various PIM libraries, often related to Akonadi integration for Workspace - Components of Workspace that were sitting over in Gear, such as Baloo (which shouldn't be used anywhere outside Plasma - yet is heavily integrated in Dolphin, which arguably really belongs in Plasma not Gear as well) - Applications that published components and libraries that were reusable by others such as Marble, Kompare and Okteta. - Addon collections that due to shared D-Bus interfaces ended up being both build and runtime dependencies (less so now, but kio-extras sits in this territory to a certain extent) - Components of Workspace, such as KSysguard that provide libraries whose functionality is used I'm not sure where KWin sits these days, but it's hard (and I mean very hard) dependency on KWindowSystem within Frameworks was a source of quite a bit of trouble in the past. Dolphin is a serial offender in the same department when it comes to KIO - it has a similarly hard dependency. > > > > > > * We currently don't have a stable branch for Framework and it > takes > > > > > often > > > > > up to one month for fixes to be deployed. The Framework releases is > > > > > also > > > > > not in sync with either Gear nor Plasma while these two modules > > > > > heavily > > > > > make use of Framework and contribute to Framework. > > > > > > Changing the Frameworks release cadence away from monthly isn't going > to > > > get fixes out any faster - as if you are using distribution packages it > > > still has to be packaged. > > > If anything it will make them take longer as the Frameworks release > would > > > end up being every couple of months instead of monthly? (you can always > > > build Frameworks locally if you need the fixes now) > > > > For (non-rolling) distributions that update packages on patch releases > but > > not on minor releases it would make a difference if there where patch > > releases of Frameworks. Not all distributions can follow and backport > > important fixes in Frameworks. At worst, users will have to suffer a bug > in > > Frameworks until the next LTS release. > > > > Regards, > > Ingo > -- > Kevin Ottens, http://ervin.ipsquad.net > > enioka Haute Couture - proud supporting member of KDE > https://hc.enioka.com/en Cheers, Ben
Re: Proposal unify back our release schedules
On Fri, Apr 19, 2024 at 9:39 AM Kevin Ottens wrote: > Hello, > > ::most history snipped:: > > And then have a single big marketing > announcement for a Plasma x.y.2 per year with its own marketing name. > > ::snip:: > > > * Only have one release announcement on our website. We can call it > > Megarelease 6.XX like we did for Plasma 6/Gear 24.02 or find a better > name. > > I would avoid reusing Software Collection first because the name is quite > > technical and second because these was already used in the past. > > Sure, why not. This is not engineering I'm less opinionated about it. > Apart > from decoupling more between engineering effort and marketing > announcements > that is. > > Maybe reconsider the "Megarelease" term though... I've literally been > laughed > at for the use of that term outside of our community. Also, I think it was > a > fine term for a one off when moving on a major new version of Qt, but > it'll > get old quickly for the "business as usual". > I suggest that if we move to do any sort of more infrequent "mega releases" we call it KDE Community Software Release or similar. "KDE" is shorthand for our community, after all; why not spell it out. Valorie > > Again no strong opinion there, but I thought I'd mention what I've seen > around > me. > > Regards. > -- > Kevin Ottens, http://ervin.ipsquad.net > > enioka Haute Couture - proud supporting member of KDE > https://hc.enioka.com/en -- she/her. "Dwell on the beauty of life. Watch the stars, and see yourself running with them." - Marcus Aurelius
Re: Proposal unify back our release schedules
On Freitag, 19. April 2024 22:51:55 CEST Jakob Petsovits wrote: ... > all KF dependencies from source. Now that all the megarelease is out, we > might want to consider relying on distro packages for KF6 by default, in > the same way that Qt is not built by default either. This would underscore > the nature of Plasma and Gear master relying on released KF, and save some > wasted energy for people who aren't contributing to KF. Oh yes. As a from-time-to-time a-little-bit contributor, it makes things so much easier if I can build an application against the KF which comes with my distro (compared to having to build everything). Alex
Re: Proposal unify back our release schedules
Hello, On Saturday 20 April 2024 15:12:48 CEST Ingo Klöcker wrote: > On Freitag, 19. April 2024 22:40:38 CEST Ben Cooksley wrote: > > On Sat, Apr 20, 2024 at 4:39 AM Kevin Ottens wrote: > > > The example you give shows Plasma depending on Gear, this shouldn't > > > happen, so > > > I'd argue: let's fix that instead. > > In my opinion the same goes for Gear depending on Plasma. Agreed, just didn't want to muddy my message and so focused on only one direction. But it's definitely a topic to explore as well. One thing I'm unsure for instance is: do we want to make Gear -> Plasma dependencies completely forbidden? We might consider this going one step too far. I could understand if a Gear app wants to provide "more integration" in a Plasma session. So mandatory Gear -> Plasma dependencies, I agree are to forbid, but optional ones? I'm less certain. > > > > * We currently don't have a stable branch for Framework and it takes > > > > often > > > > up to one month for fixes to be deployed. The Framework releases is > > > > also > > > > not in sync with either Gear nor Plasma while these two modules > > > > heavily > > > > make use of Framework and contribute to Framework. > > > > Changing the Frameworks release cadence away from monthly isn't going to > > get fixes out any faster - as if you are using distribution packages it > > still has to be packaged. > > If anything it will make them take longer as the Frameworks release would > > end up being every couple of months instead of monthly? (you can always > > build Frameworks locally if you need the fixes now) > > For (non-rolling) distributions that update packages on patch releases but > not on minor releases it would make a difference if there where patch > releases of Frameworks. Not all distributions can follow and backport > important fixes in Frameworks. At worst, users will have to suffer a bug in > Frameworks until the next LTS release. > > Regards, > Ingo -- Kevin Ottens, http://ervin.ipsquad.net enioka Haute Couture - proud supporting member of KDE https://hc.enioka.com/en signature.asc Description: This is a digitally signed message part.
Re: Proposal unify back our release schedules
On Freitag, 19. April 2024 22:40:38 CEST Ben Cooksley wrote: > On Sat, Apr 20, 2024 at 4:39 AM Kevin Ottens wrote: > > The example you give shows Plasma depending on Gear, this shouldn't > > happen, so > > I'd argue: let's fix that instead. In my opinion the same goes for Gear depending on Plasma. > > > * We currently don't have a stable branch for Framework and it takes > > > often > > > up to one month for fixes to be deployed. The Framework releases is also > > > not in sync with either Gear nor Plasma while these two modules heavily > > > make use of Framework and contribute to Framework. > > Changing the Frameworks release cadence away from monthly isn't going to > get fixes out any faster - as if you are using distribution packages it > still has to be packaged. > If anything it will make them take longer as the Frameworks release would > end up being every couple of months instead of monthly? (you can always > build Frameworks locally if you need the fixes now) For (non-rolling) distributions that update packages on patch releases but not on minor releases it would make a difference if there where patch releases of Frameworks. Not all distributions can follow and backport important fixes in Frameworks. At worst, users will have to suffer a bug in Frameworks until the next LTS release. Regards, Ingo signature.asc Description: This is a digitally signed message part.
Re: Proposal unify back our release schedules
On Freitag, 19. April 2024 14:26:45 CEST Sune Vuorela wrote: > It might make sense for plasma and gear to follow the same schedule. But > I really like what we have going with frameworks. > > One issue that leads to the 'frameworks stable, release monthly' was > that sometimes, even often, you need to add a *feature* to a framework > to address a *bug* in an application. > > If you can't relatively quickly start requiring the fixed framework, you > end up working around it in the application and forget fixing it in the > framework. I don't follow. How does a quicker Frameworks release cycle helps with this? Do you want to bump the Frameworks requirement in a patch release of the app to get the fix into the patch release? Regards, Ingo signature.asc Description: This is a digitally signed message part.
Re: Proposal unify back our release schedules
i know quite a few have responded to this, but as the big warning on this, the fact that the three parts cant be released independently, is a big warning flag that a overhaul is needed of the overlapping architecture. i know this is a big issue, and the bigger the project, the bigger the workload. i saw someone was starting on a tool to graph architecture wise at https://invent.kde.org/sdk/codevis , its still in development, but i think this will highlight where the issue pinpoints are, break the cycles, and levelize everything. when stuff actually is decoupled, the frameworks would even be able to do staggered/piped deploys and the whole dev team would have less stress.. doing 3 releases a year or doing 12+ smaller ones, deploying from the base and going up, anything that depends on other parts will have to wait and since they still work against the last stable the friction will be less. i kept an eye on the mega release 6, and if that is viewed as a success i guess we got very different views on successes, from the mailing list it looked like at best organized chaos. On Fri, Apr 19, 2024 at 1:32 PM Carl Schwan wrote: > Hello Community, > > I know this might be a controversial idea, but I would like to propose > reunify > our release schedules. I feel like splitting our releases schedules between > Frameworks, Plasma and Gear is not working as well as we intended it to be > when > we split the releases schedules for Plasma 5. This is for multiple reasons: > > * We end up with 3 different products which are released at different > times but > are connected together. Apps and Plasma both need Framework, Plasma > needs some > packages from gear like kio-extra, Gear needs some package from Plasma > like > Breeze. Coordinating all these inter-groups dependencies is complex and > was one > the reason we had to do a megarelease for Plasma 6. Also for the end > user, one > product is a lot easier to understand. > here is a architecture bug list, the fact that there are circles like this is what needs to be dealt with before even thinking of feature development, its boring, and it will break stuff, but better take the bull by the horns and deal with it.. > * This results in very frequent releases which creates a lot of work for > distros > and talking with some distro maintainers they seems to agree that having > a big > releases every 4 months is better than having constantly a new minor or > major > release from either Framework, Gear or Plasma. > a stable release should support a known set say last 3 major releases for example. (this i due to the versioning scheme yy.mm counted as a major, then patches are the minors..) the released code used by downstream its the open source value chain.. 'master' is just work in progress until its released. distros themselves have the same issue with bad architecture, so to lessen their burden with dealing with broken stuff upstream they rather take a big release 'block' then a smaller one, its just a massive monolith they deploy then. big changes are always more risky then small ones.. problem is that features are more fun than doing maintenance on old stuff.. * We currently don't have a stable branch for Framework and it takes often > up to > one month for fixes to be deployed. The Framework releases is also not > in sync > with either Gear nor Plasma while these two modules heavily make use of > Framework > and contribute to Framework. > perfect candidate for automation.. deployment really should be automated, either by bots or other means. * We could have an unified LTS release including more than just Plasma. > This is > something that distros have been asking for some time already because > having > just Plasma receiving bug-fixes but not Framework nor the apps is not > that helpful. > i personally would prefer two release ways one feature release and one long term stable release, but this adds burden on the whole organization so i know its currently a utopia dream. mostly since KDE would have to do the Qt lts releases too since without a 'upstream' open source Qt LTS a KDE LTS is pretty useless since the dependency will have a lot faster churn than the dependency, its supposed to be the other way around.. the base is stable, the features and the churn happens a lot higher up in the structure. > * In term of promotion, it is very difficult to advertise the 3 releases > because > combined we have an important release of either Gear, Plasma or > Framework every > few weeks. This is too frequent and often while a combined announcement > would > have enough content to be published in a tech newspaper. When splitting > the content > accross 2 announcements (Gear and Plasma), we reduce the content per > announcement and this makes it less interesting for the journalists to > write > about us. This doesn't come from me, this is that some journalists > directly > told me. > this is not in my wheelhouse but i guess
Re: Proposal unify back our release schedules
Others have made convincing arguments for not tying the projects together from an engineering point of view, which I find easy to agree with. I also like the current monthly KF schedule in that it allows me to submit MRs early on in a Plasma development cycle and use them in Plasma shortly afterwards. If KF release cycles were longer, there would be more of an incentive to just stick everything into a common library within Plasma directly, which doesn't benefit as many people. What could also help with proper isolation of components is a change in build system defaults. If I call kdesrc-build today with --include-dependencies for any Plasma or Gear app, by default it will build all KF dependencies from source. Now that all the megarelease is out, we might want to consider relying on distro packages for KF6 by default, in the same way that Qt is not built by default either. This would underscore the nature of Plasma and Gear master relying on released KF, and save some wasted energy for people who aren't contributing to KF. But I also wanted to emphasize that we're actually that far off from the marketing aim either. Aligned releases are still very doable without forcing everyone into a "live at HEAD" model. Neal's suggestion deserves a closer look imho: On Fri, Apr 19, 2024, at 11:50 AM, Neal Gompa wrote: > One way I think that would work well would be to realign the schedules > so that when Plasma shifts to semi-annual releases, Frameworks and > Gear would be re-aligned so that there *would* be a release that lines > up with it. That doesn't mean both can't continue to have more > releases separately, but having a release that lines up for Plasma > would help things considerably. > > The monthly release of KDE Frameworks has its downsides, and I think > in one conversation elsewhere, I suggested that KF moves to a > quarterly release cadence, where two of the releases line up with > Plasma to become MegaReleases. Gear already releases three times a > year, and switching to four times might not be so bad. > > But even if KF doesn't change and remains monthly, then it still can work. This would mean: KF: every month Gear: every 3 months Plasma: every 6 months With Gear and Plasma aligning for a semi-yearly release. Stand-alone Gear releases get their extra announcement when the full Plasma+Gear announcement is far into the past and future, with no promo timing conflicts to worry about. Honestly I don't think that KF even needs to be aligned at all if it sticks to monthly: Assuming an expanded QA/beta/bugfix period (at least 4-6 weeks?) that the longer 6-month cycle surely deserves, any KF fixes from the beta period will either get released before Plasma is even out, or very soon after. Perhaps an extra patch-level release of KF can be inserted around the time of Plasma's .0 if an important fix is needed fast. Switching KF from monthly to semi-yearly seems overkill if we just need to get post-release fixes out a little sooner. - Jakob
Re: Proposal unify back our release schedules
On Fri, Apr 19, 2024 at 11:35 AM Volker Krause wrote: > > On Freitag, 19. April 2024 11:04:33 CEST Carl Schwan wrote: > > * We currently don't have a stable branch for Framework and it takes often > > up to one month for fixes to be deployed. The Framework releases is also > > not in sync with either Gear nor Plasma while these two modules heavily > > make use of Framework and contribute to Framework. > > The fast feature-releases of KF have major advantages though, comparing to how > things worked prior to 5. They allow apps to work against released (and thus > distro-packaged) frameworks while still making it practical to contribute > needed features to KF directly. > > The alternatives are: > * Depend on KF master (like Plasma does), significantly increasing the > threshold of entry for new contributors, especially for more self-contained > apps, where you'd now have to build 70+ repos rather than a few. > * Depend on the latest release but develop new features locally rather than in > KF. I'm not sure whether we have meanwhile finally cleaned up all the forked > kdelibs classes in PIM from the 3 and 4 era due to that. > * Depend on the latest release and wait for new features to become available > before making use of them in the app, effectively increasing the delay to > reach > users to twice the release cycle. > > Ie. this makes contributing to KF less attractive from an app developer > perspective. > > > The main issues with out-of-sync KF and Plasma should have been solved with > some frameworks being moved to Plasma with KF6, if there is more of this > remaining we should look at the specific cases, for the vast majority of > frameworks I don't think we have a problem there. > > > * Helps with outside usage of our frameworks. These didn't get as much > > success as we were hoping when splitting. I think having a stable branch > > for Framework might help but this is only a guess. It would be interesting > > to know of cases where people considered using some Framework and to know > > why they decided against or for it and if this proposal would helps or not. > > I disagree with the often repeated statement that this wasn't successful. It > might not happened as widely and visibly as we might want, but KF is most > certainly used vastly more often than kdelibs ever was. And the release > schedule isn't the impediment here, it's things like dependencies and the > build system making it hard to vendor copies. > > > In effect this proposal would mean: > > > > * We do one major release every 4 months and then minor releases with a > > frequency based on the Fibonacci numbers as this releases cycle works very > > well for Plasma. Naming could be either YY.MM or Major.Minor.Path. We could > > unify that for one or the other one. Or let each component keep their > > current versioning scheme depending whether we want to merge Plama and Gear > > as product or keep it separate. I'm a bit undecided about this. > > From my app developer perspective that is fine, Fibonacci rather than > equidistant patch releases look like an improvement to me. However, assuming > the feature release interval basically remains the same. > > AFAIK Plasma is discussing a 6 month interval though, and I do understand > longer cycles are better for promo, but it means users have to wait longer for > features. It therefore also matters whether we are tying Plasma's release to > Gear or Gear's releases to Plasma here. > > > * "KDE Framework" will still exists as an entity and its ABI and API > > compatibility requirement. Only change is the release frequency and the > > introduction of a stable branch in sync with the other components. > > That part I'm against for the above mentioned reasons, KF's release frequency > is a major feature of it. > As a distribution, I found it tremendously helpful to integrate and qualify the MegaRelease. That doesn't mean that we need *every* release of KF and Gear to be MegaReleases. One way I think that would work well would be to realign the schedules so that when Plasma shifts to semi-annual releases, Frameworks and Gear would be re-aligned so that there *would* be a release that lines up with it. That doesn't mean both can't continue to have more releases separately, but having a release that lines up for Plasma would help things considerably. The monthly release of KDE Frameworks has its downsides, and I think in one conversation elsewhere, I suggested that KF moves to a quarterly release cadence, where two of the releases line up with Plasma to become MegaReleases. Gear already releases three times a year, and switching to four times might not be so bad. But even if KF doesn't change and remains monthly, then it still can work. -- 真実はいつも一つ！/ Always, there's only one truth!
Re: Proposal unify back our release schedules
On Sat, Apr 20, 2024 at 4:39 AM Kevin Ottens wrote: > Hello, > Hi all, > > Unsurprisingly I'll be pretty much aligned with Luigi, Sune and Volker > here I > think. I'll try to add a couple of extra aspects to feed the thinking on > this > topic. > On Friday 19 April 2024 11:04:33 CEST Carl Schwan wrote: > > I know this might be a controversial idea, but I would like to propose > > reunify our release schedules. I feel like splitting our releases > schedules > > between Frameworks, Plasma and Gear is not working as well as we intended > > it to be when we split the releases schedules for Plasma 5. This is for > > multiple reasons: > > > > * We end up with 3 different products which are released at different > times > > but are connected together. Apps and Plasma both need Framework, Plasma > > needs some packages from gear like kio-extra, Gear needs some package > from > > Plasma like Breeze. Coordinating all these inter-groups dependencies is > > complex and was one the reason we had to do a megarelease for Plasma 6. > > Also for the end user, one product is a lot easier to understand. > > This is an engineering topic in this case. > > And, to me, this is an excellent reason not to reunify release schedules! > Because what it tells me is that we're still having dependency issues > which > need to be solved. > > The example you give shows Plasma depending on Gear, this shouldn't > happen, so > I'd argue: let's fix that instead. > Further cutting these links would be quite beneficial from a CI perspective, so i'm definitely in favour of this. Some of the most complicated bits of maintaining the system involve the interconnections between Gear / Plasma / Independent. Unfortunately libplasma / kpipewire / plasma-activities will be fairly hard to avoid if you're targeting certain types of integration. > > Aligning the release schedules would only hide such structural issues. > > This was one of the main engineering motives to split things up: when it > wasn't splitted this would stay hidden much longer everyone being comfy > with > it. > > Now it's creating pain: perfect, that makes the issue obvious, but it > should > be addressed not masked. > > This is in part what Volker highlighted pointing out this should be less > of a > problem with key components being moved to Plasma. Again, if there are > more, > let's just address them. > > So as pointed out by Sune and Volker: this is a feature (at least in the > Frameworks case) not a bug. > > > * This results in very frequent releases which creates a lot of work for > > distros and talking with some distro maintainers they seems to agree that > > having a big releases every 4 months is better than having constantly a > new > > minor or major release from either Framework, Gear or Plasma. > > This is a downstream relationship topic in this case. > > I'm honestly unsure where the problem is though. They could decide to pick > a > set of version for the three and focus on that. They don't have and never > had > to package every single version of KDE Frameworks. > > That being said it indicates to me that we're not good at communicating > which > KDE Frameworks version a given Plasma or Gear release targets. More > coordination and communication here would make sense. > > * We currently don't have a stable branch for Framework and it takes > often > > up to one month for fixes to be deployed. The Framework releases is also > > not in sync with either Gear nor Plasma while these two modules heavily > > make use of Framework and contribute to Framework. > Changing the Frameworks release cadence away from monthly isn't going to get fixes out any faster - as if you are using distribution packages it still has to be packaged. If anything it will make them take longer as the Frameworks release would end up being every couple of months instead of monthly? (you can always build Frameworks locally if you need the fixes now) I should note that due to a combination of Gitlab configuration and various projects essentially having a hard dependency on Frameworks master (Plasma, Dolphin, looking at both of you) the CI system always supplies Frameworks master regardless of what is being built (the Gitlab configuration is fixable, but there isn't much motivation to do so when it will just cause issues and not be used) > > This is a QA and testing topic in this case. > > The intent is that master is the stable branch (as Luigi pointed out). If > it's > not stable in practice we're failing on testing on QA. So extra automated > tests, more QA and so on should be provided. Yes this is work but it has a > chance of increasing quality, changing the release cadence won't do > anything > about it. > > * We could have an unified LTS release including more than just Plasma. > This > > is something that distros have been asking for some time already because > > having just Plasma receiving bug-fixes but not Framework nor the apps is > > not that helpful. > > This is a
Re: Proposal unify back our release schedules
Hello, Wished to react to a point in there. :-) On Friday 19 April 2024 17:33:02 CEST Volker Krause wrote: > On Freitag, 19. April 2024 11:04:33 CEST Carl Schwan wrote: > > * We currently don't have a stable branch for Framework and it takes often > > up to one month for fixes to be deployed. The Framework releases is also > > not in sync with either Gear nor Plasma while these two modules heavily > > make use of Framework and contribute to Framework. > > The fast feature-releases of KF have major advantages though, comparing to > how things worked prior to 5. They allow apps to work against released (and > thus distro-packaged) frameworks while still making it practical to > contribute needed features to KF directly. > > The alternatives are: > * Depend on KF master (like Plasma does), significantly increasing the > threshold of entry for new contributors, especially for more self-contained > apps, where you'd now have to build 70+ repos rather than a few. > * Depend on the latest release but develop new features locally rather than > in KF. I'm not sure whether we have meanwhile finally cleaned up all the > forked kdelibs classes in PIM from the 3 and 4 era due to that. > * Depend on the latest release and wait for new features to become available > before making use of them in the app, effectively increasing the delay to > reach users to twice the release cycle. > > Ie. this makes contributing to KF less attractive from an app developer > perspective. > > > The main issues with out-of-sync KF and Plasma should have been solved with > some frameworks being moved to Plasma with KF6, if there is more of this > remaining we should look at the specific cases, for the vast majority of > frameworks I don't think we have a problem there. > > > * Helps with outside usage of our frameworks. These didn't get as much > > success as we were hoping when splitting. I think having a stable branch > > for Framework might help but this is only a guess. It would be interesting > > to know of cases where people considered using some Framework and to know > > why they decided against or for it and if this proposal would helps or > > not. > > I disagree with the often repeated statement that this wasn't successful. It > might not happened as widely and visibly as we might want, but KF is most > certainly used vastly more often than kdelibs ever was. And the release > schedule isn't the impediment here, it's things like dependencies and the > build system making it hard to vendor copies. > > > In effect this proposal would mean: > > > > * We do one major release every 4 months and then minor releases with a > > frequency based on the Fibonacci numbers as this releases cycle works very > > well for Plasma. Naming could be either YY.MM or Major.Minor.Path. We > > could > > unify that for one or the other one. Or let each component keep their > > current versioning scheme depending whether we want to merge Plama and > > Gear > > as product or keep it separate. I'm a bit undecided about this. > > From my app developer perspective that is fine, Fibonacci rather than > equidistant patch releases look like an improvement to me. However, assuming > the feature release interval basically remains the same. > > AFAIK Plasma is discussing a 6 month interval though, and I do understand > longer cycles are better for promo, but it means users have to wait longer > for features. It therefore also matters whether we are tying Plasma's > release to Gear or Gear's releases to Plasma here. Users waiting longer for features is not necessarily a bad thing though. One of the potential advantages is extra QA time, I assume people are happy to wait if there are less rough edges. Now if we assume the longer cycle don't lead to more QA, this becomes a balancing act... the burden on the users to discover and assimilate new features is real. So it's a bit of a trade-off between dropping a larger set of features on them increasing the chance of such features not being noticed, or pushing less features towards the user at higher frequency which is potentially higher cognitive load (they more likely to notice them all and be in a constant "learning new stuff" and "adapting to change" loop). > > * "KDE Framework" will still exists as an entity and its ABI and API > > > > compatibility requirement. Only change is the release frequency and the > > > > introduction of a stable branch in sync with the other components. > > That part I'm against for the above mentioned reasons, KF's release > frequency is a major feature of it. Regards. -- Kevin Ottens, http://ervin.ipsquad.net enioka Haute Couture - proud supporting member of KDE https://hc.enioka.com/en signature.asc Description: This is a digitally signed message part.
Re: Proposal unify back our release schedules
Hello, On Friday 19 April 2024 14:03:01 CEST Luigi Toscano wrote: > Nate Graham ha scritto: > > I expect a vast amount of discussion to result from this proposal, and I > > think that's great. It'll be good to talk about it. But I suspect in the > > end we'll likely not achieve 100% consensus, and in that event I'd like > > for us to put it to a formal KDE e.V. vote so that the topic doesn't > > become stale and die after everyone's exhausted from a long discussion. > > Is this an eV topic? I guess it was rhetorical in which case I'll humor you: no, it's not an e.V. topic. On a more serious tone: I'm actually concerned about such an early mention of an e.V. vote. This is the wrong tool and forum for this discussion. Also, I don't see the need to assume what early that it'll lead to "everyone's exhausted from a long discussion". This assumption and the mention of a vote is IMHO setting the stage for the conversation to get out of hand before any indication that it otherwise would... a bit like a self fulfilling prophecy unfortunately. I hope we won't collectively walk into it. I'd be more optimistic as despite initial push backs I see ways for a quick consensus to emerge on something different than the initial proposal. Anyway, if it would get out of hand nonetheless (I could be wrong and too optimistic after all), I'd propose to have a volunteer and *neutral* facilitator talking independently to the various parties and producing a final proposal with high chances of consensus reaching. A bit like we did at the time of the production of the KDE Manifesto. Note I wouldn't volunteer because obviously I got some more skin in the game this time and already engaged in the conversation. So if you're someone who didn't reply to this thread and have no strong opinion about the topic: keep monitoring that thread and maybe evaluate volunteering to facilitate if we start throwing mud at each other. ;-) Regards. -- Kevin Ottens, http://ervin.ipsquad.net enioka Haute Couture - proud supporting member of KDE https://hc.enioka.com/en signature.asc Description: This is a digitally signed message part.
Re: Proposal unify back our release schedules
Hello, Unsurprisingly I'll be pretty much aligned with Luigi, Sune and Volker here I think. I'll try to add a couple of extra aspects to feed the thinking on this topic. On Friday 19 April 2024 11:04:33 CEST Carl Schwan wrote: > I know this might be a controversial idea, but I would like to propose > reunify our release schedules. I feel like splitting our releases schedules > between Frameworks, Plasma and Gear is not working as well as we intended > it to be when we split the releases schedules for Plasma 5. This is for > multiple reasons: > > * We end up with 3 different products which are released at different times > but are connected together. Apps and Plasma both need Framework, Plasma > needs some packages from gear like kio-extra, Gear needs some package from > Plasma like Breeze. Coordinating all these inter-groups dependencies is > complex and was one the reason we had to do a megarelease for Plasma 6. > Also for the end user, one product is a lot easier to understand. This is an engineering topic in this case. And, to me, this is an excellent reason not to reunify release schedules! Because what it tells me is that we're still having dependency issues which need to be solved. The example you give shows Plasma depending on Gear, this shouldn't happen, so I'd argue: let's fix that instead. Aligning the release schedules would only hide such structural issues. This was one of the main engineering motives to split things up: when it wasn't splitted this would stay hidden much longer everyone being comfy with it. Now it's creating pain: perfect, that makes the issue obvious, but it should be addressed not masked. This is in part what Volker highlighted pointing out this should be less of a problem with key components being moved to Plasma. Again, if there are more, let's just address them. So as pointed out by Sune and Volker: this is a feature (at least in the Frameworks case) not a bug. > * This results in very frequent releases which creates a lot of work for > distros and talking with some distro maintainers they seems to agree that > having a big releases every 4 months is better than having constantly a new > minor or major release from either Framework, Gear or Plasma. This is a downstream relationship topic in this case. I'm honestly unsure where the problem is though. They could decide to pick a set of version for the three and focus on that. They don't have and never had to package every single version of KDE Frameworks. That being said it indicates to me that we're not good at communicating which KDE Frameworks version a given Plasma or Gear release targets. More coordination and communication here would make sense. > * We currently don't have a stable branch for Framework and it takes often > up to one month for fixes to be deployed. The Framework releases is also > not in sync with either Gear nor Plasma while these two modules heavily > make use of Framework and contribute to Framework. This is a QA and testing topic in this case. The intent is that master is the stable branch (as Luigi pointed out). If it's not stable in practice we're failing on testing on QA. So extra automated tests, more QA and so on should be provided. Yes this is work but it has a chance of increasing quality, changing the release cadence won't do anything about it. > * We could have an unified LTS release including more than just Plasma. This > is something that distros have been asking for some time already because > having just Plasma receiving bug-fixes but not Framework nor the apps is > not that helpful. This is a downstream relationship topic in this case. I'm not sure we need to go full steam on the LTS promise though. See above: better communication about the expected and QA'd versions of KDE Frameworks needed by Plasma for instance might be enough. > * In term of promotion, it is very difficult to advertise the 3 releases > because combined we have an important release of either Gear, Plasma or > Framework every few weeks. This is too frequent and often while a combined > announcement would have enough content to be published in a tech newspaper. > When splitting the content accross 2 announcements (Gear and Plasma), we > reduce the content per announcement and this makes it less interesting for > the journalists to write about us. This doesn't come from me, this is that > some journalists directly told me. This is a marketing topic in this case. I've never been really involved in the KDE marketing effort. Still, looking back at it years after I joined the community, and knowing what I know nowadays from seeing other projects and products, one thing which surprises me is that we're still on the mindset of hard coupling engineering releases and marketing announcements. I think we passed the point where it was viable a long time ago. I honestly wouldn't be shocked if there were engineering releases of KDE Frameworks and those would have just a
Re: Proposal unify back our release schedules
On Freitag, 19. April 2024 11:04:33 CEST Carl Schwan wrote: > * We currently don't have a stable branch for Framework and it takes often > up to one month for fixes to be deployed. The Framework releases is also > not in sync with either Gear nor Plasma while these two modules heavily > make use of Framework and contribute to Framework. The fast feature-releases of KF have major advantages though, comparing to how things worked prior to 5. They allow apps to work against released (and thus distro-packaged) frameworks while still making it practical to contribute needed features to KF directly. The alternatives are: * Depend on KF master (like Plasma does), significantly increasing the threshold of entry for new contributors, especially for more self-contained apps, where you'd now have to build 70+ repos rather than a few. * Depend on the latest release but develop new features locally rather than in KF. I'm not sure whether we have meanwhile finally cleaned up all the forked kdelibs classes in PIM from the 3 and 4 era due to that. * Depend on the latest release and wait for new features to become available before making use of them in the app, effectively increasing the delay to reach users to twice the release cycle. Ie. this makes contributing to KF less attractive from an app developer perspective. The main issues with out-of-sync KF and Plasma should have been solved with some frameworks being moved to Plasma with KF6, if there is more of this remaining we should look at the specific cases, for the vast majority of frameworks I don't think we have a problem there. > * Helps with outside usage of our frameworks. These didn't get as much > success as we were hoping when splitting. I think having a stable branch > for Framework might help but this is only a guess. It would be interesting > to know of cases where people considered using some Framework and to know > why they decided against or for it and if this proposal would helps or not. I disagree with the often repeated statement that this wasn't successful. It might not happened as widely and visibly as we might want, but KF is most certainly used vastly more often than kdelibs ever was. And the release schedule isn't the impediment here, it's things like dependencies and the build system making it hard to vendor copies. > In effect this proposal would mean: > > * We do one major release every 4 months and then minor releases with a > frequency based on the Fibonacci numbers as this releases cycle works very > well for Plasma. Naming could be either YY.MM or Major.Minor.Path. We could > unify that for one or the other one. Or let each component keep their > current versioning scheme depending whether we want to merge Plama and Gear > as product or keep it separate. I'm a bit undecided about this. >From my app developer perspective that is fine, Fibonacci rather than equidistant patch releases look like an improvement to me. However, assuming the feature release interval basically remains the same. AFAIK Plasma is discussing a 6 month interval though, and I do understand longer cycles are better for promo, but it means users have to wait longer for features. It therefore also matters whether we are tying Plasma's release to Gear or Gear's releases to Plasma here. > * "KDE Framework" will still exists as an entity and its ABI and API > compatibility requirement. Only change is the release frequency and the > introduction of a stable branch in sync with the other components. That part I'm against for the above mentioned reasons, KF's release frequency is a major feature of it. Regards, Volker signature.asc Description: This is a digitally signed message part.
Re: Proposal unify back our release schedules
On Friday, April 19, 2024 2:03:45 PM GMT+2 Luigi Toscano wrote: > We also have and we will continue to have applications which are not on this > schedule, and thus KDE will continue to be unfit as a general brand for > them. The work to reduce the dependencies improved with the move to Qt 6 > (for example the Frameworks-but-really-Plasma moved to Plasma), surely it > can be improved. And this is fine. For these apps, they can still continue to depends on Framework as they wish and the API and ABI stability are still guaranteed. They won't have as often a feature release of Framework but I don't expect this to be a big issue as these apps already often prefer to depend on older framework release instead of pursuing the latest release. > > * We currently don't have a stable branch for Framework and it takes often > > up to> > > one month for fixes to be deployed. The Framework releases is also not > > in sync with either Gear nor Plasma while these two modules heavily > > make use of Framework and contribute to Framework. > > But the point of Frameworks is that it should be "always stable". This is unfortunately not the case. Errors happen and I feel like having a beta period shared with the rest of the stack and a patch release one week after the release would be really helpful for the stability of Framework. > > * We could have an unified LTS release including more than just Plasma. > > This is> > > something that distros have been asking for some time already because > > having just Plasma receiving bug-fixes but not Framework nor the apps > > is not that helpful. > Wasn't it said that LTS are difficult? I've heard different voices even from > Plasma. I'm not a big fan of doing LTS release either. I just think a LTS release of gear + plasma + framework would be better than one of just Plasma. > > * In term of promotion, it is very difficult to advertise the 3 releases > > because ... > > Again, this will still leave out everything which does not happen to be part > of this 3 blocks. Which is fine. Apps outside of Gear have been doing their own release at their own pace with their own release announcement and will continue to do so. This proposal doesn't change that. It is not better or worse for them. > > * We won't have 3 different release teams but instead have a bigger one > > with a> > > bigger bus factor. We could also unify the tooling for doing this mass > > releases a bit. > > Releasing improved over time, and the tooling is definitely more unified > than before (I think Frameworks uses the same tool as Plasma). With the > discussion about improving the creating of tarballs directly from the tags, > this may be more a non-problem). It's improving and this is good. But you still need people to run the scripts at some interval, ensure that the builds are passing for everything and ping the correct people if not, move the translations to the correct branch in SVN, ... > > I do understand that there was valid reasons for splitting KDE Software > > Collection for Plasma 5 but I don't think this worked out. These were as > > far as I know the main arguments used for splitting the Software > > Collection. > > It doesn't mean moving back is the solution. Also, the split happened before > Qt5, and the reason are still there. The split is not solving the issues we were thinking it would solve and is additionally causing other issues. For me this is a clear indication that we need to rethink the split, that the current status quo is not working, and that we need to find a better solution. I'm proposing this proposal as a possible solution and indeed this might not be the only one, but this is only one I came up. Anyone is free to propose counter proposal on how to improve the situation ;) > > * Trying to move away from "KDE" being recognized as the software instead > > of the> > > community. This unfortunately didn't really work out, everyone is still > > using KDE to refer to the desktop. Even distros call their edition > > "KDE" and I don't blame them, it's difficult to find a better term than > > that as for example "Fedora KDE Spin" not only contains Plasma but also > > a lot of KDE apps. Splitting the releases won't help with that, we need > > to find a better approach or just let it go and accept that people will > > keep using KDE to describe the desktop/software. > > And again, we have and will have stuff which does not fit that. The main > problem is the Desktop which is seen as "KDE". People use "KDE" to refer to the "core" components and this includes stuff like Dolphin, Kate and Okular, it's not only the desktop. > Maybe it will take just more time and another generation of people. I don't think so and even if it did require more time, do we want to wait another decade and see if the situation improve? > > * Better promotion of our apps outside of Plasma. This is a valid point > > but I think> > > pursuing
Re: Proposal unify back our release schedules
On 2024-04-19, Carl Schwan wrote: > Hello Community, > > I know this might be a controversial idea, but I would like to propose reunify > our release schedules. I feel like splitting our releases schedules between > Frameworks, Plasma and Gear is not working as well as we intended it to be > when > we split the releases schedules for Plasma 5. This is for multiple reasons: > > * We end up with 3 different products which are released at different times > but > are connected together. Apps and Plasma both need Framework, Plasma needs > some > packages from gear like kio-extra, Gear needs some package from Plasma like > Breeze. Coordinating all these inter-groups dependencies is complex and was > one > the reason we had to do a megarelease for Plasma 6. Also for the end user, > one > product is a lot easier to understand. It might make sense for plasma and gear to follow the same schedule. But I really like what we have going with frameworks. One issue that leads to the 'frameworks stable, release monthly' was that sometimes, even often, you need to add a *feature* to a framework to address a *bug* in an application. If you can't relatively quickly start requiring the fixed framework, you end up working around it in the application and forget fixing it in the framework. I do think that that has been a great success with the frameworks release schedule. I don't think we should move away from that. /Sune
Re: Proposal unify back our release schedules
(apologize, resending, I've missed a CC) Carl Schwan ha scritto: > Hello Community, > > I know this might be a controversial idea, but I would like to propose reunify > our release schedules. I feel like splitting our releases schedules between > Frameworks, Plasma and Gear is not working as well as we intended it to be > when > we split the releases schedules for Plasma 5. This is for multiple reasons: > > * We end up with 3 different products which are released at different times > but > are connected together. Apps and Plasma both need Framework, Plasma needs > some > packages from gear like kio-extra, Gear needs some package from Plasma like > Breeze. Coordinating all these inter-groups dependencies is complex and was > one > the reason we had to do a megarelease for Plasma 6. Also for the end user, > one > product is a lot easier to understand. We also have and we will continue to have applications which are not on this schedule, and thus KDE will continue to be unfit as a general brand for them. The work to reduce the dependencies improved with the move to Qt 6 (for example the Frameworks-but-really-Plasma moved to Plasma), surely it can be improved. > * This results in very frequent releases which creates a lot of work for > distros > and talking with some distro maintainers they seems to agree that having a > big > releases every 4 months is better than having constantly a new minor or > major > release from either Framework, Gear or Plasma. > > * We currently don't have a stable branch for Framework and it takes often up > to > one month for fixes to be deployed. The Framework releases is also not in > sync > with either Gear nor Plasma while these two modules heavily make use of > Framework > and contribute to Framework. But the point of Frameworks is that it should be "always stable". > > * We could have an unified LTS release including more than just Plasma. This > is > something that distros have been asking for some time already because having > just Plasma receiving bug-fixes but not Framework nor the apps is not that > helpful. Wasn't it said that LTS are difficult? I've heard different voices even from Plasma. > > * In term of promotion, it is very difficult to advertise the 3 releases > because > combined we have an important release of either Gear, Plasma or Framework > every > few weeks. This is too frequent and often while a combined announcement > would > have enough content to be published in a tech newspaper. When splitting the > content > accross 2 announcements (Gear and Plasma), we reduce the content per > announcement and this makes it less interesting for the journalists to write > about us. This doesn't come from me, this is that some journalists directly > told me. Again, this will still leave out everything which does not happen to be part of this 3 blocks. > > * We won't have 3 different release teams but instead have a bigger one with a > bigger bus factor. We could also unify the tooling for doing this mass > releases > a bit. Releasing improved over time, and the tooling is definitely more unified than before (I think Frameworks uses the same tool as Plasma). With the discussion about improving the creating of tarballs directly from the tags, this may be more a non-problem). > > I do understand that there was valid reasons for splitting KDE Software > Collection > for Plasma 5 but I don't think this worked out. These were as far as I know > the > main arguments used for splitting the Software Collection. It doesn't mean moving back is the solution. Also, the split happened before Qt5, and the reason are still there. > > * Trying to move away from "KDE" being recognized as the software instead of > the > community. This unfortunately didn't really work out, everyone is still > using > KDE to refer to the desktop. Even distros call their edition "KDE" and I > don't blame > them, it's difficult to find a better term than that as for example "Fedora > KDE Spin" > not only contains Plasma but also a lot of KDE apps. Splitting the releases > won't > help with that, we need to find a better approach or just let it go and > accept that > people will keep using KDE to describe the desktop/software. And again, we have and will have stuff which does not fit that. The main problem is the Desktop which is seen as "KDE". Maybe it will take just more time and another generation of people. > > * Better promotion of our apps outside of Plasma. This is a valid point but I > think > pursuing our current strategy of putting our apps in many app store to be > more > effective. We could also show the platforms support of each applications > more > prominently in our releases announcements like we already do on apps.kde.org > (e.g. https://apps.kde.org/okular/). Generally Plasma releases fare a lot > better > in term of promotion than the gear announcements and showing
Re: Proposal unify back our release schedules
Nate Graham ha scritto: > I expect a vast amount of discussion to result from this proposal, and I think > that's great. It'll be good to talk about it. But I suspect in the end we'll > likely not achieve 100% consensus, and in that event I'd like for us to put it > to a formal KDE e.V. vote so that the topic doesn't become stale and die after > everyone's exhausted from a long discussion. Is this an eV topic? -- Luigi
Re: Proposal unify back our release schedules
Carl Schwan ha scritto: > Hello Community, > > I know this might be a controversial idea, but I would like to propose reunify > our release schedules. I feel like splitting our releases schedules between > Frameworks, Plasma and Gear is not working as well as we intended it to be > when > we split the releases schedules for Plasma 5. This is for multiple reasons: > > * We end up with 3 different products which are released at different times > but > are connected together. Apps and Plasma both need Framework, Plasma needs > some > packages from gear like kio-extra, Gear needs some package from Plasma like > Breeze. Coordinating all these inter-groups dependencies is complex and was > one > the reason we had to do a megarelease for Plasma 6. Also for the end user, > one > product is a lot easier to understand. We also have and we will continue to have applications which are not on this schedule, and thus KDE will continue to be unfit as a general brand for them. The work to reduce the dependencies improved with the move to Qt 6 (for example the Frameworks-but-really-Plasma moved to Plasma), surely it can be improved. > * This results in very frequent releases which creates a lot of work for > distros > and talking with some distro maintainers they seems to agree that having a > big > releases every 4 months is better than having constantly a new minor or > major > release from either Framework, Gear or Plasma. > > * We currently don't have a stable branch for Framework and it takes often up > to > one month for fixes to be deployed. The Framework releases is also not in > sync > with either Gear nor Plasma while these two modules heavily make use of > Framework > and contribute to Framework. But the point of Frameworks is that it should be "always stable". > > * We could have an unified LTS release including more than just Plasma. This > is > something that distros have been asking for some time already because having > just Plasma receiving bug-fixes but not Framework nor the apps is not that > helpful. Wasn't it said that LTS are difficult? I've heard different voices even from Plasma. > > * In term of promotion, it is very difficult to advertise the 3 releases > because > combined we have an important release of either Gear, Plasma or Framework > every > few weeks. This is too frequent and often while a combined announcement > would > have enough content to be published in a tech newspaper. When splitting the > content > accross 2 announcements (Gear and Plasma), we reduce the content per > announcement and this makes it less interesting for the journalists to write > about us. This doesn't come from me, this is that some journalists directly > told me. Again, this will still leave out everything which does not happen to be part of this 3 blocks. > > * We won't have 3 different release teams but instead have a bigger one with a > bigger bus factor. We could also unify the tooling for doing this mass > releases > a bit. Releasing improved over time, and the tooling is definitely more unified than before (I think Frameworks uses the same tool as Plasma). With the discussion about improving the creating of tarballs directly from the tags, this may be more a non-problem). > > I do understand that there was valid reasons for splitting KDE Software > Collection > for Plasma 5 but I don't think this worked out. These were as far as I know > the > main arguments used for splitting the Software Collection. It doesn't mean moving back is the solution. Also, the split happened before Qt5, and the reason are still there. > > * Trying to move away from "KDE" being recognized as the software instead of > the > community. This unfortunately didn't really work out, everyone is still > using > KDE to refer to the desktop. Even distros call their edition "KDE" and I > don't blame > them, it's difficult to find a better term than that as for example "Fedora > KDE Spin" > not only contains Plasma but also a lot of KDE apps. Splitting the releases > won't > help with that, we need to find a better approach or just let it go and > accept that > people will keep using KDE to describe the desktop/software. And again, we have and will have stuff which does not fit that. The main problem is the Desktop which is seen as "KDE". Maybe it will take just more time and another generation of people. > > * Better promotion of our apps outside of Plasma. This is a valid point but I > think > pursuing our current strategy of putting our apps in many app store to be > more > effective. We could also show the platforms support of each applications > more > prominently in our releases announcements like we already do on apps.kde.org > (e.g. https://apps.kde.org/okular/). Generally Plasma releases fare a lot > better > in term of promotion than the gear announcements and showing the > applications > on an unified
Re: Proposal unify back our release schedules
Thanks for taking the time to assemble this email, Carl. These are arguments I've brought up individually myself for years, and I think they have merit. Taken together, for me they paint a picture of a project that was attempted, faithfully executed on, but didn't end up delivering the benefits we hoped for while introducing some new drawbacks that have no easy path to being resolved. I'm in favor. I expect a vast amount of discussion to result from this proposal, and I think that's great. It'll be good to talk about it. But I suspect in the end we'll likely not achieve 100% consensus, and in that event I'd like for us to put it to a formal KDE e.V. vote so that the topic doesn't become stale and die after everyone's exhausted from a long discussion. Nate On 4/19/24 11:04, Carl Schwan wrote: Hello Community, I know this might be a controversial idea, but I would like to propose reunify our release schedules. I feel like splitting our releases schedules between Frameworks, Plasma and Gear is not working as well as we intended it to be when we split the releases schedules for Plasma 5. This is for multiple reasons: * We end up with 3 different products which are released at different times but are connected together. Apps and Plasma both need Framework, Plasma needs some packages from gear like kio-extra, Gear needs some package from Plasma like Breeze. Coordinating all these inter-groups dependencies is complex and was one the reason we had to do a megarelease for Plasma 6. Also for the end user, one product is a lot easier to understand. * This results in very frequent releases which creates a lot of work for distros and talking with some distro maintainers they seems to agree that having a big releases every 4 months is better than having constantly a new minor or major release from either Framework, Gear or Plasma. * We currently don't have a stable branch for Framework and it takes often up to one month for fixes to be deployed. The Framework releases is also not in sync with either Gear nor Plasma while these two modules heavily make use of Framework and contribute to Framework. * We could have an unified LTS release including more than just Plasma. This is something that distros have been asking for some time already because having just Plasma receiving bug-fixes but not Framework nor the apps is not that helpful. * In term of promotion, it is very difficult to advertise the 3 releases because combined we have an important release of either Gear, Plasma or Framework every few weeks. This is too frequent and often while a combined announcement would have enough content to be published in a tech newspaper. When splitting the content accross 2 announcements (Gear and Plasma), we reduce the content per announcement and this makes it less interesting for the journalists to write about us. This doesn't come from me, this is that some journalists directly told me. * We won't have 3 different release teams but instead have a bigger one with a bigger bus factor. We could also unify the tooling for doing this mass releases a bit. I do understand that there was valid reasons for splitting KDE Software Collection for Plasma 5 but I don't think this worked out. These were as far as I know the main arguments used for splitting the Software Collection. * Trying to move away from "KDE" being recognized as the software instead of the community. This unfortunately didn't really work out, everyone is still using KDE to refer to the desktop. Even distros call their edition "KDE" and I don't blame them, it's difficult to find a better term than that as for example "Fedora KDE Spin" not only contains Plasma but also a lot of KDE apps. Splitting the releases won't help with that, we need to find a better approach or just let it go and accept that people will keep using KDE to describe the desktop/software. * Better promotion of our apps outside of Plasma. This is a valid point but I think pursuing our current strategy of putting our apps in many app store to be more effective. We could also show the platforms support of each applications more prominently in our releases announcements like we already do on apps.kde.org (e.g. https://apps.kde.org/okular/). Generally Plasma releases fare a lot better in term of promotion than the gear announcements and showing the applications on an unified announcement would likely help spread the words about our applications better. * Helps with outside usage of our frameworks. These didn't get as much success as we were hoping when splitting. I think having a stable branch for Framework might help but this is only a guess. It would be interesting to know of cases where people considered using some Framework and to know why they decided against or for it and if this proposal would helps or not. In effect this proposal would
Re: Proposal unify back our release schedules
Hello Carl, Promotion-wise it makes sense. We always have difficulty explaining and, hence, making the general public feel excited about the new versions of Plasma, as the concept of "desktop environment" is a concept that escapes (and bores) most people. But promoting a bunch of new apps, and a new set of configuration tools, and a new wallpaper and widgets is a much easier thing to do. Also new versions of things like Dolphin and Spectacle, which are closely associated with Plasma, are released with Gear, while System Monitor and Discover are released with Plasma. This makes zero sense to outsiders. Tl;DR: Sounds good to me. Cheers Paul -- Promotion & Communication www: https://kde.org Mastodon: https://floss.social/@kde Facebook: https://www.facebook.com/kde/ Twitter: https://twitter.com/kdecommunity LinkedIn: https://www.linkedin.com/company/kde
