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

Reply via email to