On Jul 01, 2014, at 01:10 PM, Mathias Behrle wrote: >The first tests on suds-jurko are looking very promising. I built the package >succesfully as a drop-in replacement for the current python-suds package. It >builds correctly for python2 and python3 with all tests. I tested part of the >functionality for python2, all was working well. The maintainer of suds-jurko >is very active and responsive.
Will a Python 3 compatible suds library allow us to make progress on #732644 without rewriting bts to use REST+JSON <wink>? >1) Can I drop in the suds-jurko fork into the current suds package as >proposed by Jordan? Given that suds on PyPI hasn't been updated in almost 4 years, I think we can reasonably assume its upstream is defunct. We had a sort of analogous situation with setuptools, but the distribute and setuptools upstreams did eventually merge back together. A counter example might be oauth which was also abandoned upstream and for which a new upstream called oauthlib was released. However, in that case, the replacement was *not* API compatible, so it made sense to make it a different Debian package. I don't really have a strong opinion, as I can see both sides of the coin. You're *probably* safe just taking over the source package, but if you woke up tomorrow with an extra dose of paranoia, then you might favor a new source package, which also wouldn't be objectionable, albeit more work to transition dependencies. >2) If not 1) what would be the best alternative? > >In this case I would plan > >- a new python-suds-jurko package, conflicting with python-suds >- filing bugs to rdepends to use the new package >- removing the old package as soon as possible Yep. It's a bit ugly though (I don't like the -jurko blarg). Oh well, do what you think is right. -Barry
signature.asc
Description: PGP signature
