Bug#814479: libbusiness-creditcard-perl: New upstream version 0.35 (including new MasterCard ranges)

[gregor herrmann]

On Tue, 07 Jun 2016 12:12:42 -0700, Ivan Kohler wrote:

> The crucial point is that _we do not backport changes and create new, 
> un-QAed forks for any of this other "volatile" software like spam/virus 
> scanners and video downloads, so it seems to me that asking for it in the 
> case of libbusiness-creditcard-perl is out-of-line with our practices and 
> procedures for comparable things.  We pull in new versions of e.g. 
> spamassassin and ClamAV for the exact same reasons as this package needs 
> to be updated.

That's correct for some packages but not for others. E.g.
libdatetime-timezone-perl only updates the actual timezone data but
doesn't use new upstream releases with code changes.
 
> Specifially in regard to the desire to "avoid accidental breakage": It 
> seems that using the upstream 0.35 version, which has been QAed with my 
> company's production customers and by CPAN users for half a year, is the 
> more conservative, careful action and is the least likely to break 
> anything.  Backporting updates to an old version and creating a new 
> Debian-specific fork, which will be unable to get any kind of comparable 
> real-world testing, seems to be the riskier action that is more likely to 
> cause breakage.

Right, that's the valid counter-argument. And uploads to stable-* are
always about finding a balance.
 
> > That's true for some packages where backporting fixes is non-trivial,
> > and AFAIK noone is happy with that. In most cases the changes are
> > small and targetted.
[..]
> WRT your assertion that noone is happy with that, FWIW, I would disagree.  
> I'm very happy that my mail server gets updated versions of spamassassin 
> and ClamAV.  I'm glad we don't use our limited volunteer resources trying 
> to try to support older, less-functional, non-QAed/patched versions of 
> those packages on my stable machines like they were stable security 
> updates.

That's of course a valid point as well.
 
> > I totally agree that an update of libbusiness-creditcard-perl in
> > jessie{,-updates} (wheezy is gone by now anyway) makes sense, I just
> > want to prepare a proposal for the release team that doesn't make
> > them cringe :) That's why I'd like to strip down
> > https://metacpan.org/diff/file?target=IVAN%2FBusiness-CreditCard-0.35%2F&source=IVAN%2FBusiness-CreditCard-0.33%2F
> > to the necessary part(s) before contacting them.
> As the sole purpose of the module is to validate and identify credit 
> cards, few (if any) would even be omitted.  Since 0.33, the version in 
> jessie, _every change_ has been for the purpose of staying up-to-date 
> with real world requirements such as recognizing new cards or processing 
> agreements.  Here is the relevant section of the Changes file.
[..]
> What would you omit in a backport for jessie?  I think everything needs 
> to be included, they're all updates to keep up with the real world.

I absolutely agree that every functional change needs to be included;
but not the noise from build tools and unrelated changes in the
documentation.
 
> As with all of us in the volunteer effort, I only have a limited amount 
> of time and motivation to I only have so much time and effort to devote 
> to Debian work.  In this case, I don't personally anticipate motivating 
> for more work creating a Debian-specific, un-QAed backport in order to 
> keep release managers from "cringing".

I didn't mean to imply that it's you who has to make the changes :)
 
> For the sake of our users and free softwre (you know, our priorities), I 
> would respectfully suggest the release managers should "cringe" and deal 
> with this course of action as the least risky of the less-than-ideal 
> alternatives, with more than ample precedent (e.g. spamassassin, ClamAV, 
> etc.).

If I'm to one who talks to them I'd prefer to prepare the potential
upload in a way that I know makes it easy for them to review.

And to speed this all up a bit :) I've pushed a jessie branch to our
git repo:
https://anonscm.debian.org/cgit/pkg-perl/packages/libbusiness-creditcard-perl.git/log/?h=jessie
where I left out the non-functional changes and split the rest into
three logical patches.

What do you think? If this looks okay to you I'm happy to proceed.
 
> FWIW, we are just a few months away from the October 2016 "deadline" when 
> MasterCard is expected to start issuing cards with the new ranges.  If we 
> have not figured out how to accept these changes by then, our users could 
> start seeing their web sites refuse to accept real-world cards and lose 
> sales and money.  That would be a shame.

Thanks for pointing out this deadline; I'm confident we have
everything sorted by then :)


Cheers,
gregor 

-- 
 .''`.  Homepage https://info.comodo.priv.at/ - OpenPGP key 0xBB3A68018649AA06
 : :' : Debian GNU/Linux user, admin, and developer -  https://www.debian.org/
 `. `'  Member of VIBE!AT & SPI, fellow of the Free Software Foundation Europe
   `-   NP: Pink Floyd: Welcome To The Machine
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 949 bytes
Desc: Digital Signature
URL: <http://lists.alioth.debian.org/pipermail/pkg-perl-maintainers/attachments/20160607/50a1bc12/attachment-0001.sig>