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. -- Can't change field types https://bugs.launchpad.net/bugs/186869 You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
