Comment 35 for bug 345166

We got burned by too liberal stable updates before, several times, so we learned to be very cautious and conservative. I am sorry if you spent work with creating a point release "for us" (well, some changes are obviously for other distros/platforms), which contains too many changes. Perhaps in the future we can discuss this beforehand? In general we prefer backporting minimal patches, i. e. throwing git commit IDs into bug reports is usually the best approach. The kinds of fixes which are appropriate for stables are outlined in
https://wiki.ubuntu.com/StableReleaseUpdates#When.

> > It changes user-visible strings and thus breaks string freeze and translations

> Nope, this is not correct, unless you refer to documentation updates, in which case, well, duh. This is pretty common practice in GNOME.

I did refer to the documention, yes. It might be common practice in GNOME to break existing translations in stables, but it's not in Ubuntu.

> > Changes other parts of the code without referring to bug reports
> Because your users had yet to file any bug reports for them

My (with my SRU hat on) general POV for that is that if nobody filed a bug about something, it can hardly be so bad to justify a SRU in the first place. However, if someone (like Iain) wants to include (some of) these fixes, he can just open bugs for them and supply the necessary SRU information (justification, test cases, etc.) I wasn't saying that _you_ (Sandy) are supposed to do this work, just that we use bugs to document SRUs.

> - Translation updates: el, es

These are fine, of course (and I didn't complain about them before).

Iain, I leave it to you whether you prefer taking the new upstream release, restore the old documentation strings, and file bugs for the other changes, or just cherrypick the SRU worthy fixes (which is a lot easier to do, to review and safer, FWIW).