Comment 13 for bug 998521

Revision history for this message
Clint Byrum (clint-fewbar) wrote : Re: [Bug 998521] Re: whoopsie process is leaking memory

Excerpts from Sebastien Bacher's message of 2012-05-31 08:54:24 UTC:
> Clint, on the diff when filtering out "noise":
>
> $ debdiff --exclude *win32* --exclude tests* --exclude Makefile.in --exclude po --exclude docs --exclude ChangeLog --exclude configure --exclude *generated* glib2.0_2.32.1-0ubuntu2.dsc glib2.0_2.32.3-0ubuntu1.dsc | diffstat
> ...
> INSTALL | 4
> NEWS | 75
> README | 2
> configure.ac | 16
> debian/changelog | 12
> debian/control | 2
> debian/control.in | 2
> debian/patches/git_powerpc_gresources.patch | 28
> debian/patches/gnetworkmonitor_dont_leak_networks.patch | 21
> debian/patches/series | 2
> gio/Makefile.am | 25
> gio/dbus-daemon.xml | 76
> gio/gapplication.c | 57
> gio/gapplicationimpl-dbus.c | 6
> gio/gconverterinputstream.c | 12
> gio/gdbus-2.0/codegen/config.py | 2
> gio/gdbus-2.0/codegen/utils.py | 7
> gio/gdbusaddress.c | 306 ++
> gio/gdbusdaemon.c | 1752 ++++++++++++++++
> gio/gdbusdaemon.h | 19
> gio/gdbusprivate.c | 42
> gio/gdbusserver.c | 5
> gio/gdesktopappinfo.c | 3
> gio/gio.rc | 8
> gio/gioenums.h | 9
> gio/giomodule-priv.h | 4
> gio/giomodule.c | 6
> gio/gproxyaddressenumerator.c | 95
> gio/gresource.c | 5
> gio/gresourcefile.c | 1
> gio/gsocketcontrolmessage.c | 11
> glib/glib.rc | 8
> glib/gmain.c | 35
> glib/gutils.h | 2
> gmodule/gmodule.rc | 8
> gobject/gobject.h | 4
> gobject/gobject.rc | 8
> gthread/gthread.rc | 8
> 38 files changed, 2543 insertions(+), 145 deletions(-)
>
> so the diff is around 2690 lines, 1771 of those being the gdbusdaemon
> for win32 use, it means the remaining diff is around 900 lines of actual
> changes, it's not trivial but far from the 34k you listed
>

Agreed. Thanks for giving me some help in isolating the changes.

This is still inappropriate as an SRU. The policy is pretty clear, bugs
that can be fixed in SRU are:

* Severe regressions
* loss of user data
* Bugs which do not fit under above categories, but (1) have an obviously safe patch and (2) affect an application rather than critical infrastructure packages (like X.org or the kernel)
* New hardware
* New commercial software
* FTBFS

Policy allows micro releases if *all* of the changes match this
criteria. While the changes you filtered out are not relevant, none of
them meet this policy.

So, I can't really ignore all of those things that you filtered out.

I know that some other micro-releases that skirt this policy have been
accepted, but they matched the third criteria above. glib is critical
infrastructure, so I have to keep that in mind.

The reason for the policy isn't to be annoying. Its to preserve the SRU
team's time and make sure we are reviewing *EVERY* change that goes into
the stable release.

An appropriate SRU would just add the patch:

gnetworkmonitor_dont_leak_networks.patch.

Rejecting upload, please re-upload as a patch, not a new upstream release.