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. -- [UIFe] transmission measures bandwidth in KB/s instead of kB/s https://bugs.launchpad.net/bugs/538504 You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. -- ubuntu-bugs mailing list [email protected] https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
