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 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 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 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
(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
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
Proposal unify back our release schedules
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 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. * "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. * 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
