Proposal unify back our release schedules

[Kevin Ottens]

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 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 extragear application.

Our story regarding UI isn't great lately as you highlight here. It's a bit 
all over the place. Obviously it can't be completely prevented (makes sense 
for apps to have their own specific customs widgets or elements when it's too 
niche as you mention). But still there's room for improvement here, I don't 
think this is a small thing to fix, it's a full fledged project.

With your recent work you're uniquely placed to spearhead it BTW. I'd 
understand if it's not something you fancy though. :-)

> > > * 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.
> 
> Frameworks don't have stable releases, if distributions want bug fixes they
> currently have two choices:
> 
> - Update to the latest framework release continuously. This means they have
> to package every single version of KDE Frameworks and this is actually that
> we recommend officially for the better or worse (running a very recent
> framework release with a very old plasma is not well tested).
> - Back-port every bug fixes in the packaging of the distro. This is
> duplicated work and I would argue that this is basically a stable branch
> but maintained out of tree, which is not ideal.
> 
> My solution was to do official stable release for Framework, but there seems
> to be some resistance to that idea.

That said, as I mentioned if we communicate better the QA'd framework release 
for a given Gear + Plasma release this makes it easier already I think.

It seems to be that your amended proposal above would address this (with one 
Framework release in sync with Gear and Plasma). My proposal on top with the 
n-1 to n month being only about stabilizing and not landing features would 
reinforce the effect I guess (again: it depends on the beta phase length for 
Plasma and will to have an extra beta).

So I guess we could try this and see what it gives after a handful of Plasma 
releases.

> > > * 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.
> 
> And even with perfect QA, we won't be able to cover all mistakes and we
> regularly end up with some regression in Framework. I think this is
> partially caused by less "apps/gear" developers testing their applications
> with Framework compiled from master.

Sidenote: this reminds me of a long standing pondering I had. It's really hard 
to figure out the ratio of people who compile everything from master vs people 
who use packages and compile only their apps.

Since the beginning of my contributions I compiled everything from master. At 
some point I felt almost none of our developers were compiling on top of their 
distro packages. So I stopped doing it for years and built apps I cared about 
most on top of the distro packages.

Lately I felt like it went back the other way... so I'm compiling everything 
from master again.

I think in an ideal world it'd be 50/50. :-)

> I think at least having a beta release at the same time as the gear and
> plasma release would be beneficial even if this means we don't do a
> framework beta release for every framework release.

Yup.

> > > * 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.
> 
> I'm a bit skeptical about the general LTS releases concept for KDE and I'm
> not advocating for doing them. Unless of course some downstream entity
> decides to spend engineering time on it and then as KDE we should
> facilitate this effort. My point is that if we want to do an LTS release,
> we need to not only have an LTS release of Plasma, but also Framework and
> Gear (or at least a part of gear). And having some sort of synchronization
> for the releases of these products would help a lot to archive that.

Agreed. It's an all or nothing type of thing.

> > > * 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 don't think it is remotely possible to decouple the engineering releases
> from the marketing announcements. As soon as the tarball are publicly
> available, 20 news articles appear in the internet before we even have the
> time to publish our announcement and I'm only slightly exaggerating. Many
> distributions will have the package available on their repositories in a
> matter of hours to days. We can't publish an announcement, two months later
> or it will be old news already.

Unfortunately this feels right. I'm always underestimating how little control 
we have about this.

This limits our options indeed. Probably a good problem to have though. :-)

> And we do have engineering releases for framework which only contains the
> changelog: e.g. https://kde.org/announcements/frameworks/6/6.1.0/
> We are just not promoting these because the format is way to dry for any end
> users and developers already usually get the news on their mailbox.
>
> > 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).
> 
> Fortunately the tooling is slowly getting unified.

This is the right trend.

> > [...]
> > 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".
> 
> Yeah the megarelease term is not great. It was fine for a one time thing,
> but if we do unified releases of at least gear and plasma, we need to find
> an better name or do something else: e.g. use code names for releases like
> macOS do.

This would be nice. We used to have those a long time ago, they could be back 
this way.

Regards.
-- 
Kevin Ottens, http://ervin.ipsquad.net

enioka Haute Couture - proud supporting member of KDE
https://hc.enioka.com/en
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 195 bytes
Desc: This is a digitally signed message part.
URL: <http://mail.kde.org/pipermail/kde-community/attachments/20240422/777405b5/attachment.sig>