Gutsy: Can't change field types (needs newer stable version)

[Murray Cumming]

Binary package hint: glom

Glom 1.6.0 in Ubuntu 7.10 "Gutsy" has a bug which makes it impossible to create any fields of types other than number. Changing the field type has no effect. This makes Glom almost useless. This and many other annoying bugs are fixed in the newer Glom releases. There's also a fix in libgda to allow the use of spaces in user names and passwords. Packages already exist in the Openismus PPA:
https://launchpad.net/%7Eopenismus-team/+archive
but these should really be in regular Ubuntu Gutsy.

[Luca Falavigna (dktrkranz)]

Is it possible to isolate a patch to fix this issue?

[Murray Cumming (murrayc)]

Theoretically yes, but there are other issues fixed too, and a released tarball is generally going to be more reliable and tested than a patch. This is the stable branch of Glom, not some bundle of random changes.

[Luca Falavigna (dktrkranz)]

Is version in Hardy fixed?

Also, could you please integrate this bug as per https://wiki.ubuntu.com/StableReleaseUpdates, section "Propose" ? This will help us a lot to review your request. Thanks!

[Murray Cumming (murrayc)]

Yes, the version in Hardy fixes this issue (it has Glom 1.6.6) though Hardy's version is still old (Glom 1.6.8 is the latest version, with more bug fixes).

> Also, could you please integrate this bug as per https://wiki.ubuntu.com/StableReleaseUpdates, section "Propose" ? This will help us a lot to review your
> request. Thanks!

I don't know what you need me to do. There is no Propose section on that page. I have tried to follow that page's instructions so far.

[Murray Cumming (murrayc)]

Sorry for mistakenly "nominating for release" for Hardy. I can't remove that now.

[Luca Falavigna (dktrkranz)]

It was recently updated, information required is now under "Procedure".

[Daniel Holbach (dholbach)]

The motu-sru team needs the information mentioned at https://wiki.ubuntu.com/StableReleaseUpdates#head-a7a957d3d691c2754ba24e5085481107ed703b49

[Murray Cumming (murrayc)]

OK, so:

> Check that the bug is fixed in the current development release, and its bug report task is "Fix released".

Already done.

> Use Nominate for release to mark the bug as an SRU candidate for the appropriate Ubuntu releases (e. g. the current LTS and latest stable release),
> then subscribe [WWW] ubuntu-sru for packages in main/restricted, or [WWW] motu-sru for packages in universe/multiverse.

Already done.

> Update the bug report description and make sure it contains the following information:
> 1. A statement explaining the impact of the bug on users and justification for backporting the fix to the stable release

Already done.

> 2. An explanation of how the bug has been addressed in the development branch, including the relevant version numbers of packages modified in order to implement the fix.

Already done, I believe. It's obvious - the development branch just has the newer version.

> 3. A minimal patch applicable to the stable version of the package. If preparing a patch is likely to be time-consuming, it may be preferable to get a general approval from the SRU team first.

As stated, I don't think it's sensible for Ubuntu to have a series of patches against 1.6.0 instead of just using a newer tarball. We release bug-fix tarballs responsibly, for distros, not for the hell of it. Again, this is the stable branch of Glom, not some bundle of random changes.

> 4. Detailed instructions how to reproduce the bug. These should allow someone who is not familiar with the affected package to reproduce the bug and verify that the updated package fixes the problem. Please mark this with a line "TEST CASE:".

OK. If you insists:
TEST CASE:
- Start Glom
- Create a new file from an example, such as the Music Collection example..
- Choose the Developers/Fields menu item.
- Change a Text field to Numeric type.
- Close the Field Definitions dialog
- Reopen the Field Definitions dialog from Developers/Fields again.
- Notice that the field type is still Text.

> 5. A discussion of the regression potential of the patch and how users could get inadvertedly effected.

Already done. New stable versions of Glom have no new features and no known regessions, because it's stable.

> Upload the fixed package to release-proposed with the patch in the bug report, a detailled and user-readable changelog, and no other unrelated changes.

Obviously this is something for the package maintainer, not something for a bug reporter (me) to do.

> Once the [WWW] archive admins approve and publish your upload, test the actual binaries in the Ubuntu archive yourself and follow up in the bug report.
> Add yourself as a bug contact for the package in Launchpad, if you are not one already, and monitor Launchpad for bug reports relating to the update for at least one week.

These also seem like things for a package maintainer. But tell me if I need to do something.

So I don't see what's actually need from me. In case you can't tell, I am rather irrititated at the hoops (sometimes impossible) that a bug reporter must jump through just to get a bugfix into a stable Ubuntu release.

[Loïc Minier (lool)]

Certainly you can understand that a bug report on a random package is not the place to put in question a process as critical as stable release updates.

I understand the upstream Glom developers are responsible enough to do high quality stable releases, nevertheless the current SRU process requires a "minimal patch", typically something which a human can review and where one can claim it is a completely understood and safe change.

Perhaps this process is too strict for Glom in particular and we certainly bend the process a little for GNOME point releases for instance, but keep in mind there are also other mechanisms to bring new releases to stable users (e.g. backports) if you don't want this particular problem to be fixed.

My suggestions would be to:
- discuss the strictness of the SRU process with the Ubuntu developers at large; I believe this shouldn't happen in a bug report or on your blog, but rather on the Ubuntu mailing lists; perhaps ubuntu-devel-discuss@ or ubuntu-devel@
- in this bug, prepare a minimal patch or wait for someone to create one addressing only the grave issue you mention which requires a SRU

[Loïc Minier (lool)]

I didn't find the first version number of Glom where this bug is fixed so I grabbed the latest 1.6 release (1.6.6 currently) and compared to the one in gutsy (1.6.0).

The diff exposes:
1) changes in the build rules:
-SUBDIRS = po glom docs macros examples xslt icons
+SUBDIRS = po glom macros examples xslt icons
+
+if HAVE_GNOME_DOC_UTILS
+SUBDIRS += docs
+endif

2) addition of a maemo port and subsequent bug fixes

3) different versions of autoconf and intltool were used to release the tarball

4) implementation of new build flags --enable-maemo, --enable-maemo-launcher and --enable-client-only

5) new logic for computation of the required pkg-config modules

6) misc code changes and bug fixes

This is the diffstat:
 configure.in | 93 +-
 glom-1.6.6/ChangeLog | 196 ++++
 glom-1.6.6/Makefile.am | 6
 glom-1.6.6/NEWS | 49 +
 glom-1.6.6/aclocal.m4 | 14
 glom-1.6.6/config.h.in | 6
 glom-1.6.6/glom/Makefile.am | 62 -
 glom-1.6.6/glom/application.cc | 429 ++++++++--
 glom-1.6.6/glom/application.h | 28
 glom-1.6.6/glom/base_db.cc | 185 +++-
 glom-1.6.6/glom/base_db.h | 8
 glom-1.6.6/glom/box_db.cc | 14
 glom-1.6.6/glom/box_db_table.cc | 6
 glom-1.6.6/glom/combobox_fields.cc | 6
 glom-1.6.6/glom/combobox_relationship.cc | 14
 glom-1.6.6/glom/dialog_connection.cc | 31
 glom-1.6.6/glom/dialog_connection.h | 4
 glom-1.6.6/glom/dialog_glom.cc | 2
 glom-1.6.6/glom/dialog_invalid_data.cc | 11
 glom-1.6.6/glom/filechooser_export.cc | 13
 glom-1.6.6/glom/frame_glom.cc | 265 ++++--
 glom-1.6.6/glom/frame_glom.h | 40
 glom-1.6.6/glom/glom.glade | 177 ----
 glom-1.6.6/glom/layout_item_dialogs/box_formatting.cc | 2
 glom-1.6.6/glom/libglom/Makefile.am | 16
 glom-1.6.6/glom/libglom/appstate.cc | 11
 glom-1.6.6/glom/libglom/connectionpool.cc | 167 +++
 glom-1.6.6/glom/libglom/connectionpool.h | 28
 glom-1.6.6/glom/libglom/data_structure/field.cc | 13
 glom-1.6.6/glom/libglom/data_structure/field.h | 3
 glom-1.6.6/glom/libglom/data_structure/fieldtypes.cc ...

[Murray Cumming (murrayc)]

Thanks, but sorry, I'm not prepared to have a mutant version of Glom in Ubuntu when there's a perfectly good stable release. Nobody's patch review of the source code will be as good as the general testing of a real release. I'm also not prepared to deal with multiple conflicting patches (or the difficulties of creating and applying them in sequence) for the multiple bug-fixes. For a non-core package this is an obviously inappropriate process. I'd rather force people to use the PPA.

I will try to address this general problem elsewhere. Thanks for your help in making the situation clearer at least.

[LaserJock (laserjock)]

I'm marking the main task as "Fixed Released" as it is fixed in Hardy, and I'm accepting the Gutsy task. I think we should maybe look at this for a possible microrelease exception. MOTU SRU needs to discuss this further but I would see this as a candidate.

[Murray Cumming (murrayc)]

So what is the next step? What can I do to move this forward?

[LaserJock (laserjock)]

Sorry Murray, haven't had much time lately to look into this. I'm asking the Technical Board for clarification on microreleases.

What would be the lowest version of glom that would fix this bug? From Loïc Minier's investigation above going from 1.6.0 to 1.6.6 seems to introduce and awful lot beyond just fixing this bug. It's a slippery slope here as I'm sure there are always improvements with every release, but the more updated code we introduce the more potential for regressions and unintentional side-effects. Hopefully we can get this resolved soon, I don't like seeing bug fixes just lying around.

[Murray Cumming (murrayc)]

> What would be the lowest version of glom that would fix this bug

1.6.2, but there is no good reason not to take all the bug fixes. It's a stable branch.

By the way: You'll find it easier to read the NEWS file than the ChangeLog:
http://svn.gnome.org/viewvc/glom/branches/glom-1-6/NEWS?view=markup

The ChangeLog is for people working on the software.

> seems to introduce and awful lot beyond just fixing this bug.

Some ifdefs were added to support the Maemo platform. We did that initially in a branch but eventually it had to be brought back into the current stable version. It's all working fine in Ubuntu Hardy.

And several other bugs are fixed too. That's good. Bug fixes are good.

> the more updated code we introduce the more potential for regressions and unintentional side-effects.

That's not a real problem because nobody is using Glom for anything remotely important. The couldn't be, because no version of Ubuntu has ever had a version of Glom that didn't have a critical bug, because Ubuntu never packages the bug fixes. So it's risk free to take the latest stable version.

[Murray Cumming (murrayc)]

I'd really prefer that you just not bother than that you fix just one bug via a patch. Even while this was being discussed here, a whole bunch of other bugs were fixed:
http://svn.gnome.org/viewvc/glom/branches/glom-1-6/NEWS?view=markup

And if we have to go through this long process for every bug fix then we'll never get more than 2 or 3 of those in.

[Loïc Minier (lool)]

Ok; I'll let Jordan report back on pushing 1.6.2; the changes in 1.6.2 are much smaller than in 1.6.6.

[Murray Cumming (murrayc)]

Should this bug report be closed, given that gutsy is now obsoleted by hardy?

[Scott Kitterman (kitterman)]

No. Gutsy is still supported for another year.

[Murray Cumming (murrayc)]

OK. So, I believe there is now a new SRU process that will allow the latest stable upstream version to be taken.

[Sergio Zanchetta (primes2h)]

The 18 month support period for Gutsy Gibbon 7.10 has reached its end of life -
http://www.ubuntu.com/news/ubuntu-7.10-eol . As a result, we are closing the
Gutsy task.