Bug-fixed Glom 1.6 in Ubuntu 7.10 “Gutsy”

General,

I’m regularly annoyed that no stable version of Ubuntu has a bug-fixed version of Glom. For instance, Ubuntu Gutsy has Glom 1.6.0 and the ubuntu-updates policy does not allow it to have Glom 1.6.6. Unfortunately Glom 1.6.0 and some dependencies have bugs making it mostly unusable, such as a failure when changing field types, and not shutting PostgreSQL down properly.

The irony is that Glom is totally open source / free software and is using the recommended deployment method (shipping with the distro itself), but this doesn’t allow us to get bug fixes to users. I understand that non security bug-fixes for non-essential software is not a priority for Ubuntu but it’s frustrating for users. I suspect that they bend the rules for essential stuff like OpenOffice. I find myself wishing for a security problem to fix in Glom just so I can get the non-security bug fixes released along with the security fix.

However, Ubuntu recently created the PPA (Personal Package Archive) system, so Daniel has made some updated packages available in the Openismus PPA. Forcing people to add a repository will lose us many non-technical users but it’s the best we can do right now. I’ve updated the Glom download page.

16 thoughts on “Bug-fixed Glom 1.6 in Ubuntu 7.10 “Gutsy””

  1. Many say that one of the biggest advantages to Linux is the repositories.

    However, the nature of these repositories is that they are out of date the moment the distro ships. About every use that likes/needs new features end up running development versions of the distro.

    It is incredibly frustrating since self contained “installers” are usually not available which makes it much to hard for new users needing a specific version of a program.

  2. Hi Murray,

    You already know about the SRU process, and it might indeed not be the good solution to fix any bug in Glom in Gutsy. One reason for the strict process is to guarantee the stability of the stable release — there was at least one major problem in the past with a stable update.

    Still, it still permits fixing important issues, and what you describe sounds like an important issue: do you have Launchpad bugs ids open for these bugs? Naturally, as SRUs require a lot of work, some might get a higher priority than others.

    Furthermore, there are other solutions available to you; I’m glad you provide updated packages in a ppa, perhaps a more natural solution to your problem is to offer backports? See https://help.ubuntu.com/community/UbuntuBackports.

    Cheers,

  3. > Still, it still permits fixing important issues, and what you describe sounds like an important issue

    I guess I will try, but until now I’ve been assured by Daniel Holbach (the very helpful maintainer of the Glom package in Ubuntu, and someone who I believe knows his way around the Ubuntu processes) that these types of bugs are not enough to allow an update. There are actually no Launchpad bugs about this for Gutsy (just bugzilla.gnome.org bugs and mailing list complaints), but we’ve had similar bugs for Glom 1.4 in Feisty and Glom 1.2 in Edgy, which also couldn’t get updates to their latest minor version.

    Backports still requires the user to understand how to add a repository, so it isn’t much better. And the next version of Ubuntu should be using the next major version of Glom (not actually released yet) so it isn’t generally a way to get minor updates into a stable version of Ubuntu.

  4. The way to get Ubuntu to improve their policy is to recommend that Glom users use Fedora, which is does not suffer from this situation and atm. ships glom-1.6.5. If users move to Fedora because of the update policy, the Ubuntu guys will soon figure out how to fix this. Frankly, you should move to Fedora not just to discipline Ubuntu but to reward Fedora for doing the right thing. That’s why people moved to Ubuntu in the first place, and they were right to do so — look at the improvements it caused.

  5. Hi Murray,

    We are even dropping support for Ubuntu at work (100 workstations) due to the numerous bug-fix issues we have had with it on the desktop. So this is no surprise for me. We moved to RHEL on servers and Fedora on desktop.

    Sean

  6. “Backports still requires the user to understand how to add a repository, so it isn’t much better. And the next version of Ubuntu should be using the next major version of Glom (not actually released yet) so it isn’t generally a way to get minor updates into a stable version of Ubuntu.”

    Let me see how an Ubuntu Gutsy user can get backported software…

    1. Go to the menu and navigate to
    System > Administration > Software Source

    2. Go to the Updates tab and select Unsupported updates (gutsy-backports)

    This does not look very onerous, even for a person just following the instructions.

    So it now just looks like you are making excuses for not supporting the ubuntu backports scheme.

    Or else just rubbishing Ubuntu for its own sake.

  7. He’s not rubbishing Ubuntu. He’s illustrating the trade-off Ubuntu is making. Rubbishing Ubuntu would be nakedly supporting Ubuntu’s release policies while failing to admit that it is making tradeoffs. One can argue sensibly for Ubuntu’s policy. I think the default repositories selected in “software sources” are good choices.

    Many users don’t understand much more than point and click. Asking them to understand obtuse dialogs is out of bounds. This something the operating system should decide for them, or at least explain the choices better (they might ask: what’s an unsupported Update, what’s a backport, how is that connected with getting a more stable version of the program that I’m having trouble with?). How’s a typical user supposed to connect the dots between having trouble with a program, and having the option of changing the software sources defaults in order to get the fixed version?

    Anyway, aside from that, I imagine that for many bug fixes, their affect on stability could be accurately guessed, and those bug fixes judged to improve usability without sacrificing stability could be pushed through more quickly to the default repositories. Or not.

  8. Things would have to get much worse before I decided to switch distros, or even decided to invest the time to investigate another distro. Compared to the past with various other distros, it’s wonderful that this is the only problem I have with distributing Glom on the distro. I spent years with RedHat and got increasingly frustrated with awful quality of the initial Fedora releases, and the failure to really open up to a community. Switching to Ubuntu saved me from losing faith in Linux and gave me new hope.

    Fedora has apparently become much better since then but I’m done bouncing from distro to distro for now. I’d like us to get at least one distro really right.

    How to automatically provide bug-fixes of third-party software to users without requiring decisions by those users is a genuinely difficult problem which probably needs to be broken down into several situations. At the least, I suppose I’d like the user to be able to explicitly request an update of a specific application when he knows that it will fix a problem he has encountered. He wouldn’t be asked to think about sets of application versions (repositories) when all he wants is one version of one application.

    Better central decision-making about bug-fix updates would be better overall, but it would eventually be a problem that one group of people makes the decisions. I wouldn’t always trust the distro to decide what’s a good update and I wouldn’t always trust the application developer to decide that either.

  10. It’s sort of a two edged sword. A less strict SRU process might allow for more bug fixes to get out to users, but increases the risk of regressions.

    Unfortunately, it seems the solution being adopted is to increase the SRU paperwork effort level to a point where people find it too much of a hassle to file them. Complaints about the paperwork get stuck in a circular argument: “If you’re not willing to put in a lot of effort filing SRU paperwork, then obviously your problem isn’t important enough.” Yet people who have the skills to fix important issues generally don’t have an excess of free time; consequently raising the effort level may be throwing the baby out with the bath water.

    In doing xorg maintenance I see many requests for SRU’s of Xorg drivers. In these cases, the issue is that the risk level is perceived as much much higher, and SRU reviewers may not feel as certain when reviewing a patch that they would be able to foresee its effects in all possible corner cases. As a consequence of this, the chance of getting a driver fix SRU’d is so faint it’s rather crazy to even consider. Fortunately, in this case users plagued by driver issues are generally desperate enough to undertake extreme measures, so providing fixes via ppa’s is actually a doable workaround.

    Anyway, I definitely agree the updates process doesn’t seem to be meeting everyone’s needs as well as it should be. I also don’t have an idea what the solution would be. Users wish for an easy way to get more fixes; developers wish for simpler ways to roll out fixes to users; distro maintainers wish to prevent regressions from leaking out to the general population; sysadmins want more control over what goes out to their users. I suspect that the SRU process is trying to roll too many needs into one solution, and is really only addressing a single group’s needs. The -backports process gives users a (reasonably) easy way to get more fixes, yet I rarely see things come through it: I think for developers it’s cost/benefit is not good enough to be worth doing, and imagine that sysadmins wouldn’t want to go anywhere near it; I don’t know how much attention it gets from the distro maintainer side, but presumably it’s seen as a lower priority than the main release. For Xorg driver updates, a special updates PPA seems to me to be the only feasible option. Probably similarly for Inkscape. In general though, I can’t imagine many users will be happy with having to enable a bunch of extra repositories, though. Plus, by design it exists outside the regular distro channels so distro maintainers and sysadmins aren’t going to be likely to want to go anywhere near it.

  11. What I said back then was that minimal patches (fixing a concrete issue) would stand a better chance to get included than full release updates (which often include all kinds of other stuff).

  12. Cant belive what i read about ubuntu.
    I dont know nothing about linux, just 3 months with ubuntu after leaving Windows, and I can do the Glom update. So, idiots can do.

    After try Kexi and Openoffice base, I choose Glom.
    Cant run Mergeant (dont understand how it works and give some errors) and Rekall (crash).

    I think that Ubuntu have problems, not only Glom have this problems, but i think that the solution is to do the best, not to let pass the opportunity.

    Sorry for my english.

  13. I see two ends of a spectrum here.
    Upstream developers always want users to have the latest versions, and may find that having their users wait <=6 months is frustrating.
    Keen Ubuntu users/developers want users to have the most stable and polished experience, but may find that SRUs are too scary, and cost too much effort when they may be rejected for fear of upsetting the apple cart (even if its wheels are a bit wonky).

    I suggest combining the domain knowledge of upstream with the industriousness and tenacity of the Ubuntu community. If Murray, as developer of Glom, says that he has some patches that will fix the most serious bugs in Gutsy’s Glom, it seems reasonable to take that as being true – he has a userbase that extends beyond Ubuntu, some of whom are running the newer versions and will be providing feedback if there are regressions.
    Joe Ubuntu wants to help improve his distro and can offer to be advocate for Murray’s desires, filling out Launchpad bugs, hunting down the duplicates (a sure fire indicator that a bug is affecting a lot of users), writing the SRU and communicating with the developers charged with overseeing the SRU process.

    I think we all ideally want a rolling stable distro, but I think we all have to accept that this is inherently a huge amount of work that also makes it much harder to make significant changes. Refreshing your system every 6 months lets you hop from one known quantity to the next, instead of updating every day, every 3 days, every 2 weeks or every year and suffering the consequences of nobody else having done that exact transition of packages.
    By bringing upstreams into the process distros can allay their fears of destabilising the system, and also hopefully reduce the effort required to assess SRU proposals, freeing up time to work on the next awesome release.

  14. Daniel, I don’t think that submitting patches instead of releases to Ubuntu is a good solution. Splitting all the bug-fixes up into patches would be more work, and they’d conflict with each other, and it would require people to pretend to understand the impact of the patches when they are very unlikely to be able to do that. And it would create a mutant unofficial version of Glom, making bug reporting/fixing more difficult. What you want is for the application to have a GNOME-like release schedule (To have bug-fixes only in a stable release). And Glom does.

Comments are closed.