Re: Call for backport review: mps-youtube && pafy
Hi Zlatan,
On Wed, Jun 24, 2015 at 2:32 AM, Zlatan Todoric <zlatan@riseup.net> wrote:
> Hi Vincent,
>
> On 06/24/2015 10:20 AM, Vincent Cheng wrote:
>> Hi Zlatan,
>>
>> On Sun, Jun 21, 2015 at 4:18 AM, Zlatan Todoric <zlatan@riseup.net>
>> wrote:
>>
>>> - packages in stable are broken because of youtube api change
>>> (they work only on local playlist but youtube search, play,
>>> download etc is broken due to api change (v2 -> v3)
>>
>> I just wanted to point out that the backports ftpmasters are
>> fairly stringent in asking for backports not to be used for the
>> purpose of fixing broken packages in stable (i.e. packages that are
>> broken in stable should be fixed via stable-updates, not
>> stable-backports). Is there no way to (minimally) backport the
>> required changes to the existing packages in stable? (If so, the
>> packages should really be removed from stable first.)
>
> Well, as I stated, the package isn't broken per se, but Youtube API
> changed so it's not anymore usable for youtube search, play,
> download... if somebody create local playlist, it will still work.
"broken" in this context is defined as whether you as maintainer
believe that the package is non-functional to the point that it should
be removed from the release in question.
> Also mps-youtube and pafy in Jessie are Python2 only while now (in
> unstable and testing) they are Python3 only (so python-pafy that is in
> current Jessie doesn't build from new source and is AFAIK removed from
> unstable/testing with arrival of python3-pafy. The version I proposed
> is the first version after stable release which has rewritten gdata
> for usage of new API (which I already believe is the bare minimum of
> changes, please do give me more detailed explanation if you meant on
> something else/more). I had some conversation and talked about
"bare minimum" in this context is defined as a debdiff that is as
small as possible (long debdiffs tend to annoy the release team, and
you don't want to annoy them since they'll be the one reviewing your
debdiff if you choose to fix this in stable).
> stable-updates and backports and was pointed to backports as more sane
> approach for this situation. For the removal, I really didn't give a
> thought - both packages are fairly minor and I didn't really think
> that removal is needed (or is the appropriate procedure in this case)
> but as python3-pafy has Breaks&Replaces on python-pafy I guess it
> wouldn't hurt to remove it (but as I said, I am not sure for the
> proper procedure on this, is there documentation where I can read this?).
I fail to see how python3-pafy declaring a Breaks+Replaces
relationship with python-pafy has anything to do with whether or not
they should be removed from stable. Also, documentation on how to
remove a package from stable can be found in devref 5.9.2 [1].
For the record, I'm not keen on sponsoring a backport if it's likely
to get rejected by the backports ftpmasters (i.e. formorer and
rhonda), and they've both made it clear many times in the past (refer
to the list archives) that they really don't like seeing packages
backported just to fix bugs in stable. A round trip through
backports-NEW ending with a reject (or sitting in the queue
indefinitely) is a waste of everyone's time, after all. I suppose you
may want to just ask them directly whether or not they'd approve this
backport, and if they're ok with it, then I'd be willing to sponsor
this.
Regards,
Vincent
[1] https://www.debian.org/doc/manuals/developers-reference/pkgs.html#removing-pkgs
Reply to: