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 wa
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 we
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 extragea
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
