Transmission

Bug #538504
Comment #18

Comment 18 for bug 538504

Revision history for this message

Charles Kerr (charlesk) wrote on 2010-03-14: Re: [UIFe] transmission measures bandwidth in KB/s instead of kB/s

#18

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.

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.