KDE considers a three-month release cycle [LWN.net]

The KDE project is contemplating a proposal to move to three-month releases. The announcement of the proposal says: "Basically the idea is to cut testing time and compensate it by keeping master always in a 'releaseable' state, now that two major components are frozen it looks like it is a good time to get used to it." The resulting discussion looks to go on for a while; see also this thread where the openSUSE project registers its disapproval of the idea.

to post comments

KDE considers a three-month release cycle

Posted Jul 9, 2013 17:47 UTC (Tue) by shmerl (guest, #65921) [Link] (2 responses)

I hope this would prompt Debian to update KDE more often. Testing and Sid are still shipping KDE 4.8.

KDE considers a three-month release cycle

Posted Jul 10, 2013 8:00 UTC (Wed) by krake (guest, #55996) [Link] (1 responses)

This is mostly an artifact of the freeze for the most recent Debian stable release.
Debian unstable usually has packages for the most recent KDE release on release day or shortly after

KDE considers a three-month release cycle

Posted Jul 16, 2013 22:39 UTC (Tue) by shmerl (guest, #65921) [Link]

I see KDE 4.10 made it to unstable already.

KDE considers a three-month release cycle

Posted Jul 9, 2013 23:49 UTC (Tue) by HelloWorld (guest, #56129) [Link] (25 responses)

OpenSuse's opposition shows once more that the current model for distributing Software on Linux is fundamentally broken. Packaging should be handled upstream as everything else is just a colossal and useless waste of resources. Of course things would be much easier if there weren't the pointless split between dpkg- and rpm-based systems...

KDE considers a three-month release cycle

Posted Jul 10, 2013 8:34 UTC (Wed) by Priscus (guest, #72409) [Link]

Packaging is much more complex than just deciding on a binary format (deb versus rpm).
While I am not a packager, off the top of my head, I can think of:
- optional dependencies (which do you use, or not? which of two competing and mostly compatible libraries will you use, such as libav and ffmpeg);
- where do you want to be on the stability versus cutting edge front (and this can be a different answer for each dependency);
- what is the framework for your distribution? (systemd versus SysV versus whatever, but also default policies, filesystem structure, way to support multiarch...)
I will not even speak of naming conventions...

The deb versus rpm difference is nearly a detail compared to all the other differences in distro-specific packaging.

KDE considers a three-month release cycle

Posted Jul 10, 2013 9:12 UTC (Wed) by seyman (subscriber, #1172) [Link] (3 responses)

> Packaging should be handled upstream as everything else is just a colossal and useless waste of resources.

There is nothing preventing the KDE devs from handling packaging as things stand now.

KDE considers a three-month release cycle

Posted Jul 10, 2013 10:45 UTC (Wed) by eru (subscriber, #2753) [Link] (2 responses)

There is nothing preventing the KDE devs from handling packaging as things stand now.

But wouldn't they have to do this in subtly different ways for each distribution? A lot of work that does not contribute much towards developing KDE itself. The problem is even more acute for a sophisticated desktop environment like KDE, because from the desktop user's point of view, it is the operating system.

KDE considers a three-month release cycle

Posted Jul 10, 2013 16:04 UTC (Wed) by raven667 (guest, #5198) [Link] (1 responses)

The way to solve that problem is to pick a winner, pick a distro that they want to standardize on and package for that and only that in the upstream. That might be Fedora, openSuSE, Debian or Ubuntu, but any other system that they didn't pick will have to do what they do now and package the source release themselves rather than being able to rely on pre-built binaries from the upstream. So far most projects haven't been willing to make that kind of decision but I think it might provide leverage on the distros to standardize at a much higher level than LSB ever tried. If distros don't want to go through a lot of packaging pain they should all standardize so they can run the same upstream binaries, standardize file paths, multi arch, package formats, versions of libraries and library choices (gnutls vs. openssl, ffmpeg vs. libav, systemd vs. upstart 8-) I think that once some of these internal squabbles are put to rest that more effort can be spent making software better for the users, and users gained, than if that effort is spent in continuous integration and accounting for all the differences between systems.

KDE considers a three-month release cycle

Posted Jul 10, 2013 18:59 UTC (Wed) by shmerl (guest, #65921) [Link]

KDE already does that at least for Plasma Active. The "stock" version tested and released by the developers is using Mer infrastructure and RPM packages.

KDE considers a three-month release cycle

Posted Jul 10, 2013 20:27 UTC (Wed) by robert_s (subscriber, #42402) [Link] (7 responses)

I do not trust upstream developers one inch to sanely integrate their software into a system that has to do more than just run their package.

KDE considers a three-month release cycle

Posted Jul 10, 2013 20:46 UTC (Wed) by halla (subscriber, #14185) [Link]

Me neither, and I am one of them :-).

KDE considers a three-month release cycle

Posted Jul 10, 2013 23:45 UTC (Wed) by HelloWorld (guest, #56129) [Link] (5 responses)

If upstream developers can't get the integration right, then it's too hard in the first place. One reason so many people welcome systemd is that it offers uniform configuration files and APIs. But systemd isn't enough, a lot more work is needed in that direction.

KDE considers a three-month release cycle

Posted Jul 11, 2013 0:31 UTC (Thu) by FranTaylor (guest, #80190) [Link] (1 responses)

> If upstream developers can't get the integration right, then it's too hard in the first place.

What are you saying here?

Perhaps you are suggesting that people should not release free software unless they have bothered to download 100+ linux distributions and make sure it works on all of them.

Or are you saying that we should give up trying to package software and take up knitting instead?

What exactly are you suggesting? I'm not sure.

KDE considers a three-month release cycle

Posted Jul 11, 2013 12:29 UTC (Thu) by HelloWorld (guest, #56129) [Link]

> What are you saying here?
What part of that sentence could you possibly not understand? I'm saying that if upstream developers can't get it right, then it's too hard, and the obvious consequence is that it should be made simpler. Which includes getting rid of gratuitous differences between distributions, including, but not limited to, the proliferation of package management tools.

KDE considers a three-month release cycle

Posted Jul 11, 2013 20:56 UTC (Thu) by robert_s (subscriber, #42402) [Link] (2 responses)

>then it's too hard in the first place.

Well, I'm afraid complex systems _are complex_.

Having a operating system that can act as a usable desktop, be an Asterisk telephony server, possibly running a couchdb instance for one of your desktop applications while still preserving a sane, consistent & predictable set of patterns across the system is just _complex_.

(Speaking of couchdb, I would pick erlang/OTP as the perfect example of why I would never ever trust upstream developers to package software for my system)

KDE considers a three-month release cycle

Posted Jul 12, 2013 11:38 UTC (Fri) by tcourbon (guest, #60669) [Link] (1 responses)

Well, I'm afraid that your examples are bad ones.

In the context of the post you're responding to, you have to remember that a software is generally suitable for a use case. KDE is not supposed to run along telephony server. You find some corner case where you'll say that it's the only way but they are not the general use case and the upstream developers can't tailor their project for every specific and often bizarre use case.

Also we're speaking of a specific project here not about "operating system" as a whole. So to me your argument is invalid.

KDE considers a three-month release cycle

Posted Jul 12, 2013 12:12 UTC (Fri) by hummassa (guest, #307) [Link]

Your arguments don't hold a lot of water.

> KDE is not supposed to run along telephony server.

People use asterisk for a lot of simple stuff. One example is the possibility of sending SMS via your cell network SIM card. The thing is the other way around: "KDE is not supposed to be forbidden to run along asterisk, unless some really bad technical reason stands between the two". People throw diverse software (including *gasp* telephony servers) at Windows all the time.

> You find some corner case where you'll say that it's the only way but they are not the general use case and the upstream developers can't tailor their project for every specific and often bizarre use case.

Upstream developers should be reasonable careful. Sure, if you have the NEED to have some KDE-incompatible,X-incompatible display server that monopolizes the GPU (or some use-GPU-as-massive-parallel-coprocessor software), then it stands to reason that you cannot run KDE using that specific GPU. Beyond that, one might be getting a little lazy.

> Also we're speaking of a specific project here not about "operating system" as a whole. So to me your argument is invalid.

Debating over the meaning of "operating system", and if KDE is one of those, is not constructive. Considering KDE "a specific project" is a little underrating it, too.

KDE considers a three-month release cycle

Posted Jul 10, 2013 23:10 UTC (Wed) by Wol (subscriber, #4433) [Link] (8 responses)

Actually, focussing on dpkg and rpm completely misses the problem :-)

Why are dpkg packages compatible across distros, while rpm ones aren't? Okay, that's probably a gross simplification but it's mostly true (less so than it was).

The answer is that all dpkg systems are Debian derivatives, and as such abide by Debian conventions. But rpm systems are NOT RH derivatives (indeed, iirc, rpm was originally written by/for Caldera!!!). And SuSE pre-dates RedHat, but they're both rpm ...

Convergent and divergent evolution - rpm systems have *con*verged *towards* compatibility, while dpkg systems have evolved from a common ancestor.

90% of packaging problems have nothing to do with the packaging system, and everything to do with the conventions and choices around the package.

Cheers,
Wol

KDE considers a three-month release cycle

Posted Jul 11, 2013 0:01 UTC (Thu) by nirik (subscriber, #71) [Link]

> The answer is that all dpkg systems are Debian derivatives, and as such abide by Debian conventions. But rpm systems are NOT RH derivatives (indeed, iirc, rpm was originally written by/for Caldera!!!). And SuSE pre-dates RedHat, but they're both rpm ...

I'm not sure what universe you are from, but this is not the case. ;)

RPM was not orig written by/for Caldera.

SuSE Does predate Red Hat, but they didn't start using RPM until further down the road.

http://en.wikipedia.org/wiki/SUSE

http://en.wikipedia.org/wiki/RPM_Package_Manager

KDE considers a three-month release cycle

Posted Jul 11, 2013 4:05 UTC (Thu) by mjg59 (subscriber, #23239) [Link]

You never tried to install a Corel Linux KDE package on Debian, did you?

KDE considers a three-month release cycle

Posted Jul 11, 2013 8:50 UTC (Thu) by HelloWorld (guest, #56129) [Link] (5 responses)

> Why are dpkg packages compatible across distros, while rpm ones aren't? Okay, that's probably a gross simplification but it's mostly true
No, it's not. deb packages don't run on rpm-based system. That's my point.

KDE considers a three-month release cycle

Posted Jul 11, 2013 18:54 UTC (Thu) by dlang (guest, #313) [Link] (4 responses)

you (possibly intentionally) missed the point.

you can take a random .deb package and install it on any distro that supports .deb

the chances of being able to do this with a random .rpm package are much lower.

Is this because the dependencies;a tend to be defined better for .deb packages?

Is this because there is a lot less variety in the .deb distros? (they all are much closer to debian than the various .rpm distros are to each other)

Is there some other reason?

KDE considers a three-month release cycle

Posted Jul 11, 2013 20:43 UTC (Thu) by mathstuf (subscriber, #69389) [Link] (3 responses)

Well, Red Hat uses RPM from rpm.org while SUSE uses RPM from rpm5.org. They're fairly compatible at the spec level, but I think the .rpm files aren't 100% compatible. Not to mention package naming schemes being different. Also, rpm5.org supports Suggests/Recommends while rpm.org doesn't.

KDE considers a three-month release cycle

Posted Jul 13, 2013 10:54 UTC (Sat) by lsl (subscriber, #86508) [Link] (2 responses)

> Well, Red Hat uses RPM from rpm.org while SUSE uses RPM from rpm5.org.

I don't think that's true. OpenSUSE Factory seems to contain RPM 4.10 with rpm.org listed as source in the spec file. Mandriva/Mageia uses RPM from rpm5.org, though.

KDE considers a three-month release cycle

Posted Jul 13, 2013 16:46 UTC (Sat) by mathstuf (subscriber, #69389) [Link]

Ah, I didn't know they made the switch. They still carry a suggests/provides patch though don't they? ISTR mention that a VCS tag is supported as well.

KDE considers a three-month release cycle

Posted Jul 14, 2013 2:25 UTC (Sun) by rahulsundaram (subscriber, #21946) [Link]

A correction to your correction. Only Mandriva has switched to using rpm5. Neither openSUSE nor Mageia has any plans to do so and will continue using rpm.org software.

beyond the pale

Posted Jul 11, 2013 0:23 UTC (Thu) by FranTaylor (guest, #80190) [Link] (2 responses)

> Packaging should be handled upstream as everything else is just a colossal and useless waste of resources.

Wow this is just a boat-load of ignorance. It's just beyond the pale to think that a distribution like dd-wrt would want to package their software the same as a workstation distribution.

Have you EVER compiled a package from the source tarball? Have you noticed that it asks for optional packages? What is to be done here? Should a distribution use none of the optional packages or all of them? You seem to have an answer to this problem, would you care to share it with us?

Was it your intention to say something 100% incorrect or were you attempting some sort of sick irony or flame bait?

beyond the pale

Posted Jul 11, 2013 2:50 UTC (Thu) by raven667 (guest, #5198) [Link]

I didn't know that dd-wrt was a target for KDE...or are just saying something ridiculous for effect...

What's to be done is that the upstream should build their software with whatever options they think are best and you should be able to run that on any of the major desktop distributions. If you want something different, different options or to run on FunFranX where all directories are in upper case, then you can build it yourself.

The whole point of the comment is that the major desktops should have a high level of binary comparability between them but currently don't and that maybe if upstream desktop and app makers shipped binaries it would encourage distro makers to play along and engineer strong comparability.

beyond the pale

Posted Jul 11, 2013 9:00 UTC (Thu) by HelloWorld (guest, #56129) [Link]

> Wow this is just a boat-load of ignorance.
With a tone like this, I don't think it's worth responding. Have a nice life.

KDE considers a three-month release cycle

Posted Jul 12, 2013 2:23 UTC (Fri) by fedtroll (guest, #91489) [Link]

As a computer scientist, I think KDE should release every 3 months, with minimal testing. The faster you get KDE released, the sooner KDE will be included in Ubuntu "Mir". There is no disaster with KDE reducing its testing, only progress towards accessibility. Gnome will likely follow with 1 month releases and zero testing. What a community of Linux!

KDE considers a three-month release cycle

Posted Jul 14, 2013 8:03 UTC (Sun) by maxiaojun (guest, #91482) [Link]

Users should be aware of the fact that if they use KDE and do not upgrade regularly, their desktop software will soon become a piece of junk no one bother to care.

Oh, some people have commercial support. One big Linux company has a deal with Microsoft. Another two big Linux companies are focusing on non-KDE desktops.

Oh, there are also some local Linux companies work closely with local government. Do you fully trust your government?

Conclusion? Do not use KDE. Do not be lured by false claims about free software. Free software can be extremely bad for end users. Because those vocal in so-called community are brilliant jerks rather than end users / developers with right mind.