[tryton-debian] Offline notice (was: Please use a maintained soap library instead of deprecated python-suds.)

[Mathias Behrle]

Hi all,

* Scott Talbert: " Bug#783029: Bug#788087: python-profitbricks-client: Please
  use a maintained soap library instead of deprecated python-suds." (Thu, 9 Jul
  2015 21:19:43 -0400 (EDT)):

> On Wed, 8 Jul 2015, Mathias Behrle wrote:
> 
> >>>>>> Instead of porting python-profitbricks-client, I would prefer to take
> >>>>>> over the maintenance of suds for at least the stretch release and
> >>>>>> follow the suds-jurko releases. Some time ago, I already made sure
> >>>>>> that python-profitbricks-client works with the Python3 version of
> >>>>>> suds-jurko. What do you think?
> >>>>>
> >>>>> Basically I can not add much to #783029. Indeed there is some recent
> >>>>> action from the maintainer side. All efforts to use suds-jurko as a
> >>>>> drop-in replacement (or separate package by Lionel) were done, but
> >>>>> neither me (nor Lionel who wanted to do the same as you want to do now)
> >>>>> finally wanted to turn into a definite upstream for suds-jurko. For me
> >>>>> things are quite unchanged, but perhaps you are lucky to be able to
> >>>>> revive the contact with Jurko so you can get some feedback about his
> >>>>> future plans.
> >>>>>
> >>>>> Finally I only can recommend to evaluate the porting effort of
> >>>>> python-profitbricks-client (and possibly other rdepends of suds) vs. the
> >>>>> maintenance effort of suds-jurko. Bug reports filed against rdepends of
> >>>>> suds are available at [0]. The result of above said evaluation could of
> >>>>> course be influenced by the porting effort needed by other rdepends.
> >>>>> Basically they/we all will be thankful, if there is a maintained suds
> >>>>> alternative available.
> >>>>
> >>>> Looking at those bug reports:
> >>>> * 2 just removed the suggestion of python-suds
> >>>> * The maintainer of congruity (#788082) responded that porting to
> >>>> pysimplesoap would not be an easy effort
> >>>> * All other maintainers haven't responded yet
> >>>>
> >>>> Mathias, may become co-maintainer or adopt python-suds? I wait for your
> >>>> go before preparing suds-jurko with Python 3 support.
> >>>
> >>> Hi Benjamin,
> >>>
> >>> I would prefer the following way:
> >>>
> >>> 1) Jurko, the maintainer of suds-jurko, was offered, that his package
> >>> could take over the name from original suds on Pypi. He didn't make use of
> >>> this offer so far. That would have been a good starting point to use
> >>> suds-jurko (then suds) as a drop-in for current suds. As this is not the
> >>> case I would indeed prefer to keep the projects resp. packages separate.
> >>> As the package must go through NEW anyway for Python 3 support, this is
> >>> the cleaner way to get suds-jurko into the archive.
> >>> Could you please coordinate with Lionel, who prepared already an initial
> >>> separate suds-jurko package [0]?
> >>> Please let me know ASAP to inform Rdepends about the new package to
> >>> prevent evtl. unneeded work on their side (or do that yourself).
> >>>
> >>> 2) Please add Provides and Conflicts with python-suds (as done by Lionel).
> >>> As soon as suds-jurko will hit unstable I will add the Conflicts to
> >>> python-suds and change the package description to hint to your package.
> >>>
> >>> 3) Rdpends of python-suds will be informed to update their Depends to
> >>> python*-suds-jurko.
> >>>
> >>> 4) python-suds will be removed from the archive before the release of
> >>> stretch.
> >>>
> >>> Is this OK for you?
> >>
> >> I would much prefer to use suds-jurko as drop-in replacement for our
> >> current suds, because
> >>
> >> * suds-jurko is a fork that does not break the API
> >
> > There may be some probability for this, but Jurko himself didn't give the
> > guarantee, that the changes already done didn't affect the API. Do you want
> > to provide this guarantee?
> >
> >> * the original suds upstream is dead
> >> * the original suds could reclaim the namespace if upstream was becoming
> >> active again
> >> * rdepends don't have to change anything
> >
> > rdepends should use the new upstream explicitly (see above) instead of
> > perhaps suddenly failing because of a more or less inadvertised drop-in.
> >
> >> IMO it makes no sense to rename the Debian binary package to
> >> python-suds-jurko when you still run "import suds" instead of "import
> >> suds_jurko".
> >
> > It is not renaming a package, but indeed a new package. Just like the
> > project on Pypi is different from the still existing suds.
> 
> Hi Benjamin,
> 
> I support getting suds-jurko into Debian as well.  I am happy to help 
> maintain the package if you would like help.
> 
> Thanks,
> Scott

I just want to let you know, that I am offline now for 3 weeks. Whatever has to
be done on suds from my side shouldn't be urgent. If you agree to upload
suds-jurko as a new package (see above), please just do so and I will take the
necessary steps on suds when I am returning.

Glad to see (at least some of) you at DebConf,

Mathias

-- 

    Mathias Behrle
    PGP/GnuPG key availabable from any keyserver, ID: 0x8405BBF6
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 853 bytes
Desc: Digitale Signatur von OpenPGP
URL: <http://lists.alioth.debian.org/pipermail/tryton-debian/attachments/20150710/feefbb9d/attachment.sig>