--nextPart5622909.ZASKD2KPVS Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="utf-8"; protected-headers="v1" From: Kevin Ottens To: kde-community@kde.org, "kde-devel@kde.org" Cc: Carl Schwan Subject: Re: Proposal unify back our release schedules Date: Mon, 22 Apr 2024 20:17:59 +0200 Message-ID: <4375824.UPlyArG6xL@wintermute> In-Reply-To: <2929704.Kf3ObBfJql@fedora> MIME-Version: 1.0 Hello, On Monday 22 April 2024 18:08:04 CEST Carl Schwan wrote: > On Friday, April 19, 2024 6:39:01=E2=80=AFPM 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. >=20 > Thanks you all for raising some important points. Taking into account the > feedback, I would like to slightly change my proposal. >=20 > - 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=20 of the month. It seems this is not the case anymore (although it's hard to= =20 extrapolate from two data points: 6.0 and 6.1), so should make it easier to= =20 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 mig= ht=20 want to instead have Gear and Plasma target this. It's merely details though, a question of putting new habits in place, noth= ing=20 blocking IMHO even probably the right time to do so. > For the occasion where the Framework, Gear and Plasma, we should then ens= ure > 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 thi= s=20 point. If it's around a month you might want in fact this Frameworks n-1 to= be=20 the "beta" and having the n-1 to n month to be only about bugfixes and no=20 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=20 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 reas= on > to switch to a 6 months release cycle for Plasma, this argument should al= so > apply to Gear. I have no strong opinion about the 4 vs 6 months. Having the frequency of G= ear=20 allowing of an alignment with Plasma from time to time definitely makes sen= se. > > 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. > >=20 > > This is an engineering topic in this case. > >=20 > > And, to me, this is an excellent reason not to reunify release schedule= s! > > Because what it tells me is that we're still having dependency issues > > which need to be solved. > >=20 > > The example you give shows Plasma depending on Gear, this shouldn't > > happen, so I'd argue: let's fix that instead. > >=20 > > Aligning the release schedules would only hide such structural issues. > >=20 > > 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. > >=20 > > Now it's creating pain: perfect, that makes the issue obvious, but it > > should be addressed not masked. > >=20 > > 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. > >=20 > > So as pointed out by Sune and Volker: this is a feature (at least in the > > Frameworks case) not a bug. >=20 > I'm been working a lot on the visual of applications across the whole sta= ck > 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. >=20 > 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 t= he > definition of framework and allow GPL stuff). >=20 > Framework holds qqc2-desktop-style and breeze-icons as well as a lot of > custom widgets frameworks like Kirigami, KWidgetsAddons, KConfigWidgets, > KItemView, KXmlGui, ... >=20 > There are also a lot of libraries in gear which contains custom widgets (a > lot in PIM but not only). >=20 > 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 fr= om > 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. >=20 > 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= =20 all over the place. Obviously it can't be completely prevented (makes sense= =20 for apps to have their own specific customs widgets or elements when it's t= oo=20 niche as you mention). But still there's room for improvement here, I don't= =20 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=20 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. > >=20 > > This is a downstream relationship topic in this case. > >=20 > > I'm honestly unsure where the problem is though. They could decide to p= ick > > 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. > >=20 > > 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. Mo= re > > coordination and communication here would make sense. >=20 > Frameworks don't have stable releases, if distributions want bug fixes th= ey > currently have two choices: >=20 > - Update to the latest framework release continuously. This means they ha= ve > to package every single version of KDE Frameworks and this is actually th= at > 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. >=20 > My solution was to do official stable release for Framework, but there se= ems > to be some resistance to that idea. That said, as I mentioned if we communicate better the QA'd framework relea= se=20 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 on= e=20 =46ramework release in sync with Gear and Plasma). My proposal on top with = the=20 n-1 to n month being only about stabilizing and not landing features would= =20 reinforce the effect I guess (again: it depends on the beta phase length fo= r=20 Plasma and will to have an extra beta). So I guess we could try this and see what it gives after a handful of Plasm= a=20 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 modul= es > > > heavily make use of Framework and contribute to Framework. > >=20 > > This is a QA and testing topic in this case. > >=20 > > 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. >=20 > 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 h= ard=20 to figure out the ratio of people who compile everything from master vs peo= ple=20 who use packages and compile only their apps. Since the beginning of my contributions I compiled everything from master. = At=20 some point I felt almost none of our developers were compiling on top of th= eir=20 distro packages. So I stopped doing it for years and built apps I cared abo= ut=20 most on top of the distro packages. Lately I felt like it went back the other way... so I'm compiling everythin= g=20 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 Plasm= a. > > > 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. > >=20 > > This is a downstream relationship topic in this case. > >=20 > > 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. >=20 > 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 relea= ses > > > 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. > >=20 > > This is a marketing topic in this case. > >=20 > > 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. > >=20 > > I think we passed the point where it was viable a long time ago. > >=20 > > 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 marketi= ng > > name. >=20 > 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 lat= er > or it will be old news already. Unfortunately this feels right. I'm always underestimating how little contr= ol=20 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. > >=20 > > > * We won't have 3 different release teams but instead have a bigger o= ne > > > with a bigger bus factor. We could also unify the tooling for doing t= his > > > mass releases a bit. > >=20 > > This is an engineering topic in this case (to be more accurate release > > engineering). > >=20 > > There are two aspects here: the number of people and the tooling. Getti= ng > > more people would be good but if not, indeed that could be the same peo= ple > > pulling the trigger for rolling out the releases. > >=20 > > 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). >=20 > 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 versi= on > > of Qt, but it'll get old quickly for the "business as usual". >=20 > 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 ba= ck=20 this way. Regards. =2D-=20 Kevin Ottens, http://ervin.ipsquad.net enioka Haute Couture - proud supporting member of KDE https://hc.enioka.com/en --nextPart5622909.ZASKD2KPVS Content-Type: application/pgp-signature; name="signature.asc" Content-Description: This is a digitally signed message part. Content-Transfer-Encoding: 7Bit -----BEGIN PGP SIGNATURE----- iF0EABECAB0WIQQXFmpSdcX6bxpI/XgHS7vLjezJ4gUCZiap1wAKCRAHS7vLjezJ 4hztAJ9HXG58vKPNLZiDZzErWzpiuGdOogCePS5A6Xm7Fyy8hdvPQ6gjYQUMFas= =amKP -----END PGP SIGNATURE----- --nextPart5622909.ZASKD2KPVS--