Hi,

(Disclaimer: I'm not a KDE packager, just a user and an occasional
contributor)

> It is, you (as in opensuse) just have to get over the drama of having small 
> features in on each release.
> 
> Let's try to analyze a bit why some distros have this panic to new versions 
> containing features (when it comes to KDE).

This is not just about KDE. It's the policy of the distributions,
applying to all packages. For example, in the case of Debian, you are
only allowed to upload packages during the freeze if they are
bugfix-only, and if they fix a real bug that affects Debian. I imagine
the SuSE policy is similar. There's not going to be an exception for KDE.
(I don't know the precise rules for backports to stable, but the KDE
packaging team in KDE is busy enough keeping track of upstream, thus
backports rarely happen)

> For the longest amount of time in KDE4 has been releasing as a whole doing a 
> big release every 6 months. This had the following impact of how things were 
> developed:
> -People would develop super big features, some times even new apps.
> -People would push last minutes features to avoid the freeze (if you don't get 
> in then you had to wait up to 8 months for next release).
> -People would merge things that are not ready because if something is wrong a 
> bit was not a big deal (you had months to amend it).
> -Each release contained a lot of code changed.
> 
> These things (plus others less important imho) produced that the first release 
> (X.X.0) would suck and it wouldn't be until X.X.2 that it will become stable 
> (at which point developers would be already working on X.X+1).

I agree that the situation had to change. I suppose I'm not the only one
who usually waited for the .1 release before updating (when I was still
compiling it all myself).

> So this is our attempt to improve quality:
> -Develop really small features (if a feature is big, split it), put them in 
> master the moment they are ready.
> -No freezes and short release cycles, if you fail to put your thing on the 
> release X you can do it one more after. No big deal.
> -Merging things that are not unittested and/or without review will not be 
> allowed.
> -Make smaller releases, less changes less possibility of messing it up.
> 
> This workflow (or similar) is being used successfully in a lot of other free 
> software projects that are as big as we are. It has helped them to increase 
> quality and to make releases more stable. I believe it will allow us to do the 
> same.

Your proposal reminds me very much of how systemd is released. They now
have a semi-official stable repository with branches for LTS versions
<http://cgit.freedesktop.org/systemd/systemd-stable/> which I think is
managed by distributions.

My impression (as an outsider) from this discussion is that
distributions would prefer such a stable branch to be managed by KDE
devs - i.e., which version becomes LTS is decided by distributions and
according to their release schedule, but it would be a tremendous help
if developers of the respective frameworks could push bugfixes to the
stable branch as well (plus all the usual CI, automatic compile-testing
and unit tests and so on, for those branches). However, that branch
would come with "no support" from upstream, partially releasing KDE from
the burden of always maintaining two branches.

Either way, I wonder where user bugreports are supposed to be going, and
which version scheme they ought to use. Distribution bugtrackers (in my
experience) are already full of KDE bugs that nobody ever looks at
again, as the packagers maintain dozens of applications and hardly know
their inner workings. Upstream, the developer (knowing his code,
hopefully ;-) will typically have a look at it once, so there's a chance
the issue gets fixed (though if there's no reply within two weeks, it's
usually not worth waiting any longer...).
So I usually report upstream, or not at all. But with upstream being
master-only, could I only report upstream after building current master
and testing the problem there?

Kind regards
Ralf
_______________________________________________
release-team mailing list
release-team@kde.org
https://mail.kde.org/mailman/listinfo/release-team