From kde-community Sat Apr 20 11:14:26 2024 From: =?UTF-8?B?QmrDtnJuIFN0csO2bWJlcmc=?= Date: Sat, 20 Apr 2024 11:14:26 +0000 To: kde-community Subject: Re: Proposal unify back our release schedules Message-Id: X-MARC-Message: https://marc.info/?l=kde-community&m=171361371311295 MIME-Version: 1 Content-Type: multipart/mixed; boundary="--000000000000749e770616854f18" --000000000000749e770616854f18 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable i know quite a few have responded to this, but as the big warning on this, the fact that the three parts cant be released independently, is a big warning flag that a overhaul is needed of the overlapping architecture. i know this is a big issue, and the bigger the project, the bigger the workload. i saw someone was starting on a tool to graph architecture wise at https://invent.kde.org/sdk/codevis , its still in development, but i think this will highlight where the issue pinpoints are, break the cycles, and levelize everything. when stuff actually is decoupled, the frameworks would even be able to do staggered/piped deploys and the whole dev team would have less stress.. doing 3 releases a year or doing 12+ smaller ones, deploying from the base and going up, anything that depends on other parts will have to wait and since they still work against the last stable the friction will be less. i kept an eye on the mega release 6, and if that is viewed as a success i guess we got very different views on successes, from the mailing list it looked like at best organized chaos. On Fri, Apr 19, 2024 at 1:32=E2=80=AFPM Carl Schwan wr= ote: > 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 betwe= en > Frameworks, Plasma and Gear is not working as well as we intended it to b= e > when > we split the releases schedules for Plasma 5. This is for multiple reason= s: > > * 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. > here is a architecture bug list, the fact that there are circles like this is what needs to be dealt with before even thinking of feature development, its boring, and it will break stuff, but better take the bull by the horns and deal with it.. > * 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 havin= g > a big > releases every 4 months is better than having constantly a new minor or > major > release from either Framework, Gear or Plasma. > a stable release should support a known set say last 3 major releases for example. (this i due to the versioning scheme yy.mm counted as a major, then patches are the minors..) the released code used by downstream its the open source value chain.. 'master' is just work in progress until its released. distros themselves have the same issue with bad architecture, so to lessen their burden with dealing with broken stuff upstream they rather take a big release 'block' then a smaller one, its just a massive monolith they deploy then. big changes are always more risky then small ones.. problem is that features are more fun than doing maintenance on old stuff.. * 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. > perfect candidate for automation.. deployment really should be automated, either by bots or other means. * 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. > i personally would prefer two release ways one feature release and one long term stable release, but this adds burden on the whole organization so i know its currently a utopia dream. mostly since KDE would have to do the Qt lts releases too since without a 'upstream' open source Qt LTS a KDE LTS is pretty useless since the dependency will have a lot faster churn than the dependency, its supposed to be the other way around.. the base is stable, the features and the churn happens a lot higher up in the structure. > * 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 not in my wheelhouse but i guess the most important stuff when it comes to promotion and journalists is the visible stuff, they don't care about maintenance, but unless the features are produced on a stable base, you get the tower of babel and the maintenance debt will slowly kill the project. > * 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. > break it down to 12 smaller releases and let the release teams prepare one each, when a release is done, don't just throw the pig over the wall, let the release team analyze how to make the next release better, continuous improvement.when a release is done, cleanup afterwards.. next team will do the same process... smaller blocks/pieces and read on the mythical man month by Fred Brooks, its still valid.... https://en.wikipedia.org/wiki/The_Mythical_Man-Month > 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 a problem for the PR. department.. imho its not a problem if people say KDE spin, most places the actual desktop environment is displayed as Plasma, it has taken many years to build the KDE brand, use it and be proud of it. when Plasma as a name has a few decades as a brand that will start to rub off, i still remember KDE as a brand since i was a kid with my first slackware linux dual boot back in the late 90's. for me its KDE. no matter what the distro calls it. > * 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 application= s > 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. > absolutely needed, i found the codevis i linked above by browsing invent.kde.org.. there is a lot of KDE apps and libraries that i never even knew they existed until i went through the whole invent.kde.org, its a big list of stuff, to big to overview what even depends on other stuff so I've just written it off as a big monolith, and unusable in my architecture, due to lack of clean overviewable dependency tables on every library. codevis will likely be able to produce nice tables, those should be published on apps.kde.org and even more on the page for the massive bunch of libraries that is a mess to even try and overview what pulls dependencies on what.. > > * 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 decid= ed > against or for it and if this proposal would helps or not. > its a mess trying to deduce what the frameworks actually depends on without going through them one by one. every release should contain a full dependency tree file somewhere, make it easier to depend on the stuff that already have been written, otherwise we will keep re-inventing the wheel.. > > 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 f= or > 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 because the name is quite technical and secon= d > because > these was already used in the past. > > Currently this is just a proposal, not a vote proposal or anything like > that. I'll be > happy to receive positive or negative feedback on this idea. > > Cheers, > Carl as i have written, break down the releases into smaller chunks, release more often and keep compatibility with older releases. until the code is releases it is not valuable to the users. release as a mega release, then you have one big mega monolith, its just spread out over a gigantic code-base spanning hundreds of repositories, its a mess to work with as downstream. hopefully i have not stepped on to many toes... with kind regards Bj=C3=B6rn --000000000000749e770616854f18 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
i know quite a few have responded to this, but as the= big warning on this, the fact that the three parts cant be released indepe= ndently, is a big warning flag that a overhaul is needed of the overlapping= architecture.

i know this is a big issue, and the= bigger the project, the bigger the workload. i saw someone was starting on= a tool to graph architecture wise at https://invent.kde.org/sdk/codevis , its still in development= ,=C2=A0
but i think this will highlight where the issue pinpoints= are, break the cycles, and levelize everything. when stuff actually is dec= oupled, the frameworks would even be able to do staggered/piped deploys and= the whole dev team would have less stress..

doing= 3 releases a year or doing 12+ smaller ones, deploying from the base and g= oing up, anything that depends on other parts will have to wait and since t= hey still work against the last stable the friction will be less.

i kept an eye on the mega release 6, and if that is vi= ewed as a success i guess we got very different views on successes, from th= e mailing list it looked like at best organized chaos.

<= /div>

On Fri, Apr 19, 2024 at 1:32=E2=80=AFPM Carl Schwan <carl@carlschwan.eu> wrote:
<= blockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-l= eft:1px solid rgb(204,204,204);padding-left:1ex">Hello Community,

I know this might be a controversial idea, but I would like to propose reun= ify
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
=C2=A0 are connected together. Apps and Plasma both need Framework, Plasma = needs some
=C2=A0 packages from gear like kio-extra, Gear needs some package from Plas= ma like
=C2=A0 Breeze. Coordinating all these inter-groups dependencies is complex = and was one
=C2=A0 the reason we had to do a megarelease for Plasma 6. Also for the end= user, one
=C2=A0 product is a lot easier to understand.

here is a architecture bug list, the fact that there are circles lik= e this is what needs to be dealt with before even thinking of feature devel= opment,=C2=A0
its boring, and it will break stuff, but better tak= e the bull by the horns and deal with it..
=C2=A0
* This results in very frequent releases which creates a lot of work for di= stros
=C2=A0 and talking with some distro maintainers they seems to agree that ha= ving a big
=C2=A0 releases every 4 months is better than having constantly a new minor= or major
=C2=A0 release from either Framework, Gear or Plasma.
= =C2=A0
a stable release should support a known set say last 3 maj= or releases for example. (this i due to the versioning scheme yy.mm counted as a major, then patches are the minors..)
the released code used by downstream its the open source value = chain.. 'master' is just work in progress until its released.
=
distros themselves have the same issue with bad architecture, so to le= ssen their burden with dealing with broken stuff upstream they rather take = a big release 'block' then a smaller one, its just a massive monoli= th they deploy then.

big changes are always more r= isky then small ones.. problem is that features are more fun than doing mai= ntenance on old stuff..


* We currently don't have a stable branch for Framework and it takes of= ten up to
=C2=A0 one month for fixes to be deployed. The Framework releases is also n= ot in sync
=C2=A0 with either Gear nor Plasma while these two modules heavily make use= of Framework
=C2=A0 and contribute to Framework.
=C2=A0
p= erfect candidate for automation.. deployment really should be automated, ei= ther by bots or other means.

* We could have an unified LTS release including more than just Plasma. Thi= s is
=C2=A0 something that distros have been asking for some time already becaus= e having
=C2=A0 just Plasma receiving bug-fixes but not Framework nor the apps is no= t that helpful.

i personally would= prefer two release ways one feature release and=20 one long term stable release, but this adds burden on the whole organizatio= n so i know its currently a utopia dream.=C2=A0
mostly since KDE w= ould have to do the Qt lts releases too since without a 'upstream' = open source Qt LTS a=C2=A0KDE LTS=C2=A0 is pretty useless since the depende= ncy will have a lot faster churn than the dependency,=C2=A0
its s= upposed to be the other way around.. the base is stable, the features and t= he churn happens a lot higher up in the structure.
=C2= =A0
* In term of promotion, it is very difficult to advertise the 3 releases be= cause
=C2=A0 combined we have an important release of either Gear, Plasma or Fram= ework every
=C2=A0 few weeks. This is too frequent and often while a combined announcem= ent would
=C2=A0 have enough content to be published in a tech newspaper. When splitt= ing the content
=C2=A0 accross 2 announcements (Gear and Plasma), we reduce the content per=
=C2=A0 announcement and this makes it less interesting for the journalists = to write
=C2=A0 about us. This doesn't come from me, this is that some journalis= ts directly
=C2=A0 told me.

this is not in my wheel= house but i guess the most important stuff when it comes to promotion and j= ournalists is the visible stuff,=C2=A0
they don't care about = maintenance, but unless the features are produced on a stable base, you get= the tower of babel and the maintenance debt will slowly kill the project.<= br>

=C2=A0
* We won't have 3 different release teams but instead have a bigger one= with a
=C2=A0 bigger bus factor. We could also unify the tooling for doing this ma= ss releases
=C2=A0 a bit.

break it down to 12 small= er releases and let the release teams prepare one each, when a release is d= one, don't just throw the pig over the wall,=C2=A0
let the re= lease team analyze how to make the next release better, continuous improvem= ent.when a release is done, cleanup afterwards..=C2=A0

=
next team will do the same process... smaller blocks/pieces and read o= n the mythical man month by Fred Brooks, its still valid.... https://en.wikipedia.org= /wiki/The_Mythical_Man-Month
=C2=A0


I do understand that there was valid reasons for splitting KDE Software Col= lection
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
=C2=A0 community. This unfortunately didn't really work out, everyone i= s still using
=C2=A0 KDE to refer to the desktop. Even distros call their edition "K= DE" and I don't blame
=C2=A0 them, it's difficult to find a better term than that as for exam= ple "Fedora KDE Spin"
=C2=A0 not only contains Plasma but also a lot of KDE apps. Splitting the r= eleases won't
=C2=A0 help with that, we need to find a better approach or just let it go = and accept that
=C2=A0 people will keep using KDE to describe the desktop/software.

this is a problem for the PR. department..=C2= =A0=C2=A0
imho its not a problem if people say KDE spin, most pla= ces the actual desktop environment is displayed as Plasma, it has taken man= y years to build the KDE brand, use it and be proud of it.
when P= lasma as a name has a few decades as a brand that will start to rub off, i = still remember KDE as a brand since i was a kid with my first slackware lin= ux dual boot back in the late 90's.

for me its= KDE. no matter what the distro calls it.
=C2=A0
* Better promotion of our apps outside of Plasma. This is a valid point but= I think
=C2=A0 pursuing our current strategy of putting our apps in many app store = to be more
=C2=A0 effective. We could also show the platforms support of each applicat= ions more
=C2=A0 prominently in our releases announcements like we already do on apps.kde.o= rg
=C2=A0 (e.g. https://apps.kde.org/okular/). Generally Plasma release= s fare a lot better
=C2=A0 in term of promotion than the gear announcements and showing the app= lications
=C2=A0 on an unified announcement would likely help spread the words about = our applications
=C2=A0 better.

absolutely needed, i fou= nd the codevis i linked above by browsing invent.kde.org..
there is a lot of KDE apps and librari= es that i never even knew they existed until i went through the whole invent.kde.org, its a big list of stuff,= =C2=A0
to big to overview what even depends on other stuff so I&#= 39;ve just written it off as a big monolith, and unusable in my architectur= e, due to lack of clean overviewable dependency tables on every library.

=C2=A0

* Helps with outside usage of our frameworks. These didn't get as much = success
=C2=A0 as we were hoping when splitting. I think having a stable branch for= Framework
=C2=A0 might help but this is only a guess. It would be interesting to know= of cases
=C2=A0 where people considered using some Framework and to know why they de= cided
=C2=A0 against or for it and if this proposal would helps or not.

its a mess trying to deduce what the frameworks = actually depends on without going through them one by one.
every = release should contain a full dependency tree file somewhere, make it easie= r to depend on the stuff that already have been written, otherwise we will = keep re-inventing the wheel..
=C2=A0

In effect this proposal would mean:

* We do one major release every 4 months and then minor releases with a fre= quency
=C2=A0 based on the Fibonacci numbers as this releases cycle works very wel= l for
=C2=A0 Plasma. Naming could be either YY.MM or Major.Minor.Path. We could unify that=
=C2=A0 for one or the other one. Or let each component keep their current v= ersioning
=C2=A0 scheme depending whether we want to merge Plama and Gear as product = or
=C2=A0 keep it separate. I'm a bit undecided about this.

* "KDE Framework" will still exists as an entity and its ABI and = API
=C2=A0 compatibility requirement. Only change is the release frequency and = the introduction
=C2=A0 of a stable branch in sync with the other components.

* Only have one release announcement on our website. We can call it Megarel= ease
=C2=A0 6.XX like we did for Plasma 6/Gear 24.02 or find a better name. I wo= uld avoid reusing
=C2=A0 Software Collection first because the name is quite technical and se= cond because
=C2=A0 these was already used in the past.

Currently this is just a proposal, not a vote proposal or anything like tha= t. I'll be
happy to receive positive or negative feedback on this idea.

Cheers,
Carl

as i have written, break down the rele= ases into smaller chunks, release more often and keep compatibility with ol= der releases. until the code is releases it is not valuable to the users.
release as a mega release, then you have one big mega monolith, it= s just spread out over a gigantic code-base spanning hundreds of repositori= es, its a mess to work with as downstream.

hop= efully i have not stepped on to many toes...

w= ith kind regards
Bj=C3=B6rn
--000000000000749e770616854f18--