ubuntu shouldn't package beta version of digikam; needs upgrading to fix >200 bugs, and in particular import crashes #8 most reported KDE bug ever.

Digikam 1.0.0 final release is available in Karmic backports repositories. See this page for more info:
https://help.ubuntu.com/community/UbuntuBackports

So I have to enable a non-default repository whose name is "**Unsupported** updates"?

Why not just ship this as a regular update; almost every single Ubuntu user who uses digikam is going to be exposed to this bug, and if not then by the sound of it probably some other known/fixed bug. Shipping the fixes to those issues, in a way that the average Ubuntu user will actually receive them, seems like the obvious thing to do.

I can understand if the bugs were only fixed in digikam-1.1 then that would be shipped in a separate opt-in backports repository to aleviate any compatibility issues. However, a minor version upgrade from a beta release to the final release of a software is something that belongs in a given distro version's updates repository. If Ubuntu isn't willing to take that policy, it shouldn't choose to ship beta software in the initial release, or it's dooming itself to this kind of issue.

Agreed, and true, shipping beta version in Karmic was mistake, we should avoid doing this in future. However, changes between Beta5 and final version are too big to be accepted as Stable Release Update, that is why we had to resort to Backports.

Unfortunately, there's nothing that can be done about it now. :(

In the words of a friend "It's too buggy in the current release, so we can't upgrade to the version that works". This is absolutely ridiculous from an end-user perspective. While I can understand the rule in general, in this case, it's the *exact* opposite of what would be best for users.

Just to be clear: digikam is effectively useless in Karmic because of this.

(and gthumb import also has a bug that prevents import from working at all if there are movie files on the "disk", so these coupled together pretty much make Karmic in general useless for photo management).

Sigh.

Stephen, I am sorry that you feel this way. As I said, solution is to install digikam from karmic-backports repository. You can install just digikam (and kipi-plugins), if you are concerned about "unsupported" status of backports (to prevent other backported packages to install).

For digikam itself, I can only assure you that the karmic backport version (1.0.0) will have same (or even better) attention than "supported" version.

For "supported" version in karmic, we could only get single fix for the crash (a bit hard to hunt actual patches as there were several changes for this crash issue), but this will not make our users happier, as they would probably then get other beta5 issue, that need attention. It is not useful use of our limited resources to do that (and yes, this is mostly done by community resources).

Full disclosure: I'm the friend quoted by Stephen above. I'm just trying to provide some feedback on this whole thing, so take it as you will.

I'm imagining that there's some policy that you must stick with *EXACTLY* the version of what was released, and back-porting the fixes that are required. However, that seems to me to mean that only issues which get reported to the Ubuntu team in Launchpad get fixed, and results that the community resources are spread thin because of duplication of effort between the Ubuntu maintainers and upstream.

By this I mean that if Python (mentioned simply because I'm a committer there and most familiar with it) has a bug tracker, and does it's own releases of 2.6.0, 2.6.1, 2.6.2..., that really what needs to happen is that we mirror all bugs that go into those releases into launchpad so that you can be sure to keep the Ubuntu release up to date.

The option I would expect is that when we release a Python 2.6.3, for example, that we are stating that it's got the recommended set of updates from 2.6.2. I don't fully understand why you would spend the effort on cherry picking patches between the two when we've already done all that work for you. I imagine this might be due to some projects that don't do a very good job of making micro release numbers indicate only the recommended patches for people running the previous major/minor numbers, but that seems like it would be something you'd want an exception for rather than enforcing it on everyone.

Particularly, it seems like picking 1.0.0beta5 of digikam was a signal that you wanted 1.0.0 in Karmic, but it just wasn't available for the release. In other words, the 1.0.0 release when available really seems not surprising to put in place.

I mean, if the rules really are that you can't just wholesale upgrade to the 1.0.0 release, and you have to keep it beta5 with patches back-ported, it would seem like the Right Thing To Do would be to grab beta5 and 1.0.0, diff them, and use that as the patch-set for your 1.0.0beta5 packages.

As someone who did beta testing of digikam at beta5 through the 1.0.0 release, I can say with some little authority that 1.0.0 is very preferable to beta5.

Having it in backports makes it much less usable. As a user who recently gave a presentation on Digikam to our local Linux Users Group, I can say that the thought never crossed my mind that 1.0.0 would be in backports, I just figured that you hadn't gotten around to updating to it yet. I was going to grab the source for Lucid and build it, but I didn't have time, so I ended up demonstrating it on Fedora, where they *DID* release initial beta packages and then push out the 1.0.0 release once it was available.

Sean