Comment 18 for bug 538504

Revision history for this message
Charles Kerr (charlesk) wrote : Re: [UIFe] transmission measures bandwidth in KB/s instead of kB/s

Transmission has a long history of working closely with Ubuntu -- for two examples, see the upstream integration of libappindicator, and see how many Transmission tickets I've triaged in launchpad.

However, the libappindicator patch was completed a month ago. Why was this ticket filed after the feature freeze, after the UI freeze, after the beta 1 freeze? Why should Transmission introduce new code -- code which behaves differently on different systems, no less, so that'll be a joy to validate -- during the freeze of an LTS release?

That said, one of Transmission's main goals is to work seamlessly on all platforms. If this really is widely accepted Ubuntu policy -- and by that I mean not that two people wrote a UnitPolicy wiki page, but rather that a wider group of peers have seen and understood the problems generated by forking g_format_size_for_display(), etc. and still want to go through with this -- then I'll happily consider a patch for inclusion.

These are the technical constraints I would have to follow for such a patch, so I request that you follow the same constraints:

  1. The units *must* be consistent between Transmission's input fields and display output
  2. The units *must* be consistent between Transmission and the platform it's running on

These have been discussed upthread, and also in <https://bugs.launchpad.net/ubuntu/+source/glib2.0/+bug/538783>. Without these two, there's no point in patching. Now for the possible pitfalls:

  3. It *should* not break backwards compatibility with settings.json's base 2 fields. If it does so, the other applications that use settings.json (transmission-daemon, transmision-cli, transmission-qt) will need to be reviewed for ripple effects.
  4. It *must* not break the behavior of RPC/JSON's base 2 fields. There are too many third-party apps to review.
  5. It *should* not change libtransmission's interface wrt settings.json fields passed directly into tr_sessionInit(), tr_sessionSetSpeedLimit(), etc. If libtransmission's API and/or its handling of configuration key/value pairs is changed, then other applications which use libtransmission directly, particularly the Mac OS X client, will need to be reviewed for ripple effects.
 6. It *must* not add new library dependencies (such as, for example, transmission-daemon linking against glib to pick up g_format_size_for_display()) that would hamstring Transmission's viability on routers and embedded systems.
 7. It must be tested and not introduce new bugs.

If you're up for that, please be my guest.