Glom 1.6 bug fixes

We didn’t do a new major version of Glom recently, though we usually follow the GNOME schedule, because some of the new features are not quite ready, such as the drag-and-drop layout, and the new printout designer.

But this does mean that we have a chance to get a bug-fixed version of Glom’s stable version into Ubuntu’s stable version, for the first time. I’ve had some success with that, thanks to Chris Brotherton. It can still take a long time (10 days last time, though it felt like longer), and the longer it takes the more chance there is that a change in some other package can be a reason to wait. But I have a feeling that things are getting easier.

Of course, the more usable Glom is in Ubuntu, the more bug reports we can get. Many thanks to Jani Monoses and Pavel Mlčoch for keeping me busy, particularly for discovering the problems with changed behaviour in PostgreSQL 8.3, which we discovered late because PostgreSQL 8.3 only just started working for some people recently. These bugfixes mean yet more tarball releases for Ubuntu to package, and there’s always the risk that they will stop taking new versions as they really hit their freeze. Hopefully, they’ll manage to do just one more update because Jani found some more critical bugs.

After Ubuntu Hardy is released then our upstream bug fixes will probably never get into Ubuntu Hardy unless we can claim that they are security problems, as is still the problem with Glom in Ubuntu Gutsy. At FOSSCamp in Prague in May I’m apparently meant to be leading some discussion about how to get stable updates into stable distros. I have some ideas about who a distro (and its users) should trust, and about what is currently just providing a false sense of security at the cost of user experience. I don’t know what to expect from FOSSCamp so it might not have any effect. I didn’t see the point in flying to the last FOSSCamp in Boston for one day just for some seemingly aimless meeting and talking, but Prague is not far away by train, so it’s worth a look.

4 thoughts on “Glom 1.6 bug fixes

  1. Murray,

    Would you not be offended if I proffered the notion that for exactly the reason you outlined above, and numerous others, Glom and many other apps should reside outside the mother-ship repository?

    Decentralized package-management needs to come, and Ubuntu needs to step out of the sandbox.

    Sincerely,
    –Rob J. Caskey

  2. Rob: Well, Openismus also provides up-to-date at it’s PPA[1], but this aproach has problems:

    1) PPA archives are hard to find. How to you tell users which PPA to use?
    2) Forcing upstream developers to build and test packages for any major Linux distribution doesn’t scale. Upstream developers depend on the hard work of distribution packagers to get their softwares to users. Also a good software developer is not neccessarily a good software package. Programming needs certain skills: Abstract problems, find solutions, … Packaging needs quite different skills: Pedantic attention to details, good testing skills, feature resistance, …

    Also I believe that the distributed approach doesn’t work for packages. RedHat did quite radical changes in RedHat Linux 9, so many RedHad users (including me) decided to stay with RedHat Linux 7.3. Over the time the 7.3 packages became out-dated, so user maintained, distributed package archives started to show up. This worked pretty nice, when you used only one or two custom package archives, but the more archives you added, the more incompatible overlaps occured, since different package archives offered quite different back-ports of the same package. After some months the situation became that bad, that at least I had to gave up and decide between upgrading to 9, or taking another distro.

    [1] https://launchpad.net/~openismus-team/+archive

  3. Rob, I agree with Mathias. I don’t know how decentralized package management would work. Currently the advantage of being part of Ubuntu universe or Fedora extras or whatever is mostly that the package is rebuilt when dependencies change, so it’s always installable, and so we’ll know if it isn’t. And we (the developers) don’t have to worry about making packaging mistakes or subjecting our users to those mistakes.

    I spent a long time developing software for users and wrestling with horrors like Installshield, so I know that people can learn to live with the worst that it can get. But maybe they would be less tolerant if they have a choice.

    So I like the idea but I don’t know how it could be done. I think it might depend on a radically simpler way to package software, and something like Launchpad that’s actually open source.

  4. Muray, no easy answers from me, I would like to see what someone well-grounded in trust-metrics could come up with, so that the problem could be phrased as “Seed Group X, what packages should I have installed?” Lock them in a room for a year with a HIG expert and throw in some coders around day 270.

    –Rob

Comments are closed.