Fwd: Re: Fwd: KDE Frameworks Release Cycle

Wed Apr 30 15:24:42 UTC 2014

On Wednesday 30 April 2014 16:22:43 Ralf Jung wrote:
> 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.
We can do this with CI doing backports, any commit with BACKPORT will get 
cherry-picked (or at least it will be attempted).

> 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?
This is a problem that already exists, for example in bluedevil I have had 
enormous problems because distros would have either an ancient version or a 
git snapshot.

Current situation is:
Opensuse 13.1 has a BlueZ5 and they don't ship with bluedevil because at the 
time it was not ported. Now I work only on bluedevil2 (which works on bluez5) 
but their bluez version is ancient (5.8 while upstream is 5.18) so there are 
many problems who's root is the BlueZ version.  
Because of this I waste enormous amount of time just saying "sorry this is a 
downstream problem" which is a sucky message to send to users.

Kubuntu 14.04: They still release with BlueZ4 meaning that they use BlueDevil 
1.3. I can't install BlueZ4 on my machine so... who gives the support for 
that? I will release a new 1.3.X but I haven't been ablet o test it.

Fedora20: They were the first (and the only) to coordinate with me regarding 
BlueZ5. They have BlueZ5.18 which is the same I use for development.

So, technically speaking I would love to accept only bugs from Fedora since 
they use the same version of Bluez5 that I do. This is not feasible though.

So with frameworks I think we can compromise with something like "last 5 
releases" and turn off "auto reporting" for anything older than that (this is 
just an example).

Cheers.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 836 bytes
Desc: This is a digitally signed message part.
URL: <http://mail.kde.org/pipermail/release-team/attachments/20140430/a8dc142b/attachment.sig>