Le vendredi 29 décembre 2006 à 10:48 -0800, Thomas Bushnell BSG a écrit : > Despite what Josselin has said, I can see no indication from a brief > perusal of the upstream branch sources in trac that upstream gnucash > either no longer uses these key files or has changed away from the keys > with embedded spaces. Then they must stop using GKeyFile. There is no way that they will get this supported by GLib developers. > 1) Decide that glib should not migrate into testing (it is a freeze, > after all); if there are particular fixes of RC issues in more recent > versions, then those fixes should be added, but otherwise the wholesale > importation of many changes should not be permitted. That leaves us with the silent data loss that can happen when using broken key names (like, well, gnucash does). Whether this is or not a RC issue, I'll let the release team decide. > 2) Decide that glib can migrate into testing, with the particular change > of checking key values reverted to its pre-2.12.5 behavior, since this > is a destabilizing change in the Debian context. Same answer. At least we can get the other bug fixes. > 3) Decide that glib can migrate into testing with the destabilizing > change intact, migrate an upstream gnucash fix into testing at the same > time. This is the sanest solution because this is the one that gets us with the lesser number of bugs. -- .''`. : :' : We are debian.org. Lower your prices, surrender your code. `. `' We will add your hardware and software distinctiveness to `- our own. Resistance is futile.
Attachment:
signature.asc
Description: Ceci est une partie de message =?ISO-8859-1?Q?num=E9riquement?= =?ISO-8859-1?Q?_sign=E9e?=