Refreshing the ITP information:

 * Package name    : wader
   Version         : 0.5.8-1
   Upstream Author : Andrew Bird
 * URL             : https://github.com/andrewbird/wader
 * License         : GPL-2+
   Section         : net

It builds those binary packages:

wader-core - alternative D-Bus service for managing modems

Long description:
 A drop-in replacement for modemmanager and alternative implementation of the
 ModemManager API, with extensive support for many UMTS devices, simple plugin
 system for supporting new devices, robust USSD stack, multipart SMS, MMS
 reception, extensible AT engine, handles binary SMS cleanly, and can provide
 a Python shell to interact with a device during runtime.
 .
 If your 3G device does not work well with ModemManager, you may wish to try
 wader-core as an alternative.


To answer previous questions of:
        "What does wader{,-core} do that can't be done in modemmanager?"

>From a user's perspective, you get support for devices that MM
does not support:
        https://github.com/andrewbird/wader/blob/master/SUPPORTED_DEVICES

The user perspective is the one I consider most important in this
discussion.

>From a developer's perspective, writing a wader-core plugin to
support a new device is *much* simpler than writing a new MM
plugin. Additionally, certain implementation details, such as the
USSD stack in wader-core are more robust than MM equivalents.

>From a software engineering perspective, it's nice to have two
implementations of the same API, because it really helps to
verify the API.

The two projects are quite aware of each other, and I would
prefer not to step in the middle of their politics. I would
simply like to make the additional choice available in debian.

No one likes to see a divided user base and a divided developer
pool; however, this is a problem that I think is outside the
scope of what is reasonable to ask a downstream packager to
solve. ;)

In my ideal world, by making wader-core more easily installable
and accessible via the debian archive, people can study it and
figure out how to make the two upstream projects converge over
time. In the short term, let's get it into the archive first.



-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Reply via email to