* Paul Tagliamonte: " Re: [py3porters-devel] Packaging of suds-jurko" (Tue, 21 Apr 2015 17:58:45 -0400):
> On Tue, Apr 21, 2015 at 11:53:08PM +0200, Mathias Behrle wrote: > > Hi together, > > Heyya, Mathias! Hi Paul, > > My concerns so far are not for backward incompatibility, but for a rather > > reliably maintained upstream. I was in regluar contact with jurko, who said > > to suffer from shortages in ressources. So for now it can be seen, that the > > project receives a lot of public attention (issues, pull requests)and is > > widely used[0], but the last commit dates from last year[1] and development > > seems to stagnate. > > Do you see this as a worse issue than suds itself (suds upstream) also > going unmaintained? The situation with suds-jurko for sure is not worse, but the problem is more generally to get more or keep unmaintained software in the archive. > > So from my side I am still hesitating and will wait further with pushing > > suds-jurko as a replacement for python-suds. > > Is there a downside to shipping it? Are there regressions? I only see it > as a step forward from the archive, not a step back, do you agree? If > so, why not use it as a stop gap? My thoughts: - When providing a quite unmaintained suds(-jurko) we will have to maintain the evtl. necessary patches there. So it boils down a little bit, where the patches go: to python-suds or to evtl. rdepends. - When not providing a python3-suds package, the pressure on rdepends is slightly higher to consider using another well maintained SOAP client providing python3 support. Soon we will be at the beginning of a new release cycle, so there will be quite some time for rdepends to adapt. So my reservation with providing a python3-suds as a stop gap is, that this will rather fix unsane conditions than moving forward. > > If pysimplesoap [2][3] proves to > > be a well maintained project providing all necessary features, it should be > > the preferable target for a Python2/Python3 SOAP client. > > Sure, for upstreams that are willing to accept a port to a new library, > I guess I'm wondering what we'll do for upstreams that have roughly > Python 3 compatable code, but with suds; I'd hate to overhaul their code > in a debian/patches/ patch to change a library they use unless we need > to I surely won't get in the way of my Debian fellows, if I am told that it is considered useful to have suds-jurko under the actual circumstances in the archive. While trying to contact Jurko once more I will be glad to hear your opinions. AFAIR the work already done[0] and dating from July last year resulted in a functional package, so usually there shouldn't big drawbacks in getting this done provided there weren't any API changes in the meantime (which I don't expect). Cheers, Mathias [0] https://alioth.debian.org/plugins/scmgit/cgi-bin/gitweb.cgi?p=tryton/suds.git;a=shortlog;h=refs/heads/py3-drop_in_suds_jurko-WIP -- Mathias Behrle PGP/GnuPG key availabable from any keyserver, ID: 0x8405BBF6
pgpFNsp3B773w.pgp
Description: Digitale Signatur von OpenPGP