Proposal unify back our release schedules

[Ben Cooksley]

On Sat, Apr 20, 2024 at 4:39 AM Kevin Ottens <ervin at kde.org> 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 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 changelog email, same thing for
> Plasma
> x.y.0 with no marketing announcement. And then have a single big marketing
> announcement for a Plasma x.y.2 per year with its own marketing name.
>
> I'm not saying the paragraph above is exactly what we should do in terms
> of
> numbers, I'm just giving a rough example of how decoupling could look
> like.
> There are several different strategies to achieve this.
>
> > * 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.
>
> This is an engineering topic in this case (to be more accurate release
> engineering).
>
> There are two aspects here: the number of people and the tooling. Getting
> more
> people would be good but if not, indeed that could be the same people
> pulling
> the trigger for rolling out the releases.
>
> The tooling should indeed be unified as much as possible if that's not
> already
> the case. Executing a release should be the least work possible (if we
> don't
> consider the QA efforts, this is hard to compress).
>
> > 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.
>
> This is incorrect in my humble opinion. My memory could fail me of course,
> but
> to me the splitting didn't happen "to move away from KDE being recognized
> as
> the software". This marketing move actually happened before. It just so
> happen
> that the splitting made it easier on the marketing side to identify the
> products.
>
> The motive for splitting was mainly to a) be able to cater to different
> contributors and users needs and b) make structural problems more obvious.
>
> > * 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.
>
> Again, nothing to do with the split in my opinion. Like I mentioned before
> if
> marketing prefers to do a single announcement for Plasma + Gear when they
> see
> fit, this could totally happen today without a change on the engineering
> side.
>
> > * 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.
>
> Did KDE Frameworks take the Qt/C++ ecosystem by storm being used
> everywhere?
> No, indeed. We were not delusional though it wasn't the goal. We wanted to
> move from kdelibs is unusable outside of the KDE community to making it
> usable
> by third parties.
>
> We can agree to disagree on the threshold at which this is considered a
> success. But to me it's definitely a success.
>
> We moved to unused to some use both in other communities and in company
> projects we don't hear about on those lists (but they do exist). As Volker
> mentioned it's the dependencies and build system which are the limiting
> factor
> here (no wonder the most reused outside of KDE tend to be Tier 1
> frameworks).
>
>
> At this point, I think this highlights quite a bit the problems I have
> with
> this proposal. It is based on fragile premises conflating many different
> aspects. Also, instead of really addressing the issues, it's a proposal to
> move back to some "golden age of when we released everything in sync"
> which
> wouldn't solve all of the issues but only some of them (maybe)... and rub
> the
> rest under the carpet.
>
> To me the most likely outcome is old and tough issues creeping back up.
> Give
> it enough time and entropy will run its course getting us back to the
> kdelibs
> big ball of mud and high coupling of all apps Plasma and otherwise to this
> kdelibs-ng. We spent years trying to get out of this particular mess, I'd
> appreciate if we don't jump back into it.
>
> It'd also mean that the progress made on third parties using KDE
> Frameworks
> would completely go away. And in "fool me once, not twice" fashion we'd
> hardly
> get a chance of attracting them again.
>
> > 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.
>
> Indeed, the Fibonacci approach seems to work well for stabilizing minor
> releases of apps. Still, between minor releases the cadence should be
> constant.
>
> I think Gear and Plasma should be separate products. Which doesn't exclude
> moving some apps from Gear to Plasma. To me this both strengthen Plasma
> and
> Gear if we're clear where things stand.
>
> If an application is in Plasma it is expected to have a mandatory deep
> integration with Plasma sessions. If it's in Gear it is expected to be
> portable, maybe it does more under a Plasma session, but it shouldn't be
> crippled by running outside of a Plasma session.
>
> Also, on the Plasma and Gear products I think it should be clearer which
> KDE
> Frameworks version is targeted.
>
> > * "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.
>
> I hope by now I made the case clear that the release cadence of this one
> is an
> intended feature and not a bug. In my opinion, any pain KDE Frameworks
> being
> on its own cadence creates somewhere else should be treated as a symptom
> of a
> structural problem and addressed for what it is (decoupling required, some
> component in the wrong product being an issue in the dependency chain,
> missing
> QA or automated tests to catch regressions, etc.).
>
> Fun fact: "back then" we even toyed with the idea of an even faster
> cadence,
> it'd require quite some more automated QA and so was left on the side.
> I still think it would be a possibility for a subset of frameworks for go
> on a
> faster cadence, but let's not open that can of worms.
>
> > * 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".
>
> 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


Cheers,
Ben
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.kde.org/pipermail/kde-community/attachments/20240420/03d26bbc/attachment-0001.htm>