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

Tue Jun 7 19:12:42 UTC 2016

On Tue, Jun 07, 2016 at 11:58:19AM +0200, gregor herrmann wrote:
> In other words, there are no uploads to only stable-updates, just to
> stable(-proposed-updates) which may or may not also be copied over to
> stable-updates. That's why I'm talking about "uploading to stable".

I certainly don't have any current knowledge of the process and I am 
quite happy to take your word for it.  I didn't realize there were so 
many changes since it used to be "volatile".

> > > we'd need a minimal diff
> > > against the versions in wheezy/jessie (0.31 and 0.33), then we can
> > > talk to the release team about them accepting uploads.
> > I do not believe a "minimal diff" is necessary for -updates.  This is not 
> > a security backport.  This is an update for software which requires 
> > alignment to the real work to remain relevant and useful.
> 
> Sure but the release team has to inspect the changes, that's why they
> prefer minimal diffs with only the necessary changes, and also to
> avoid accidental breakage.
> 
> Cf. https://www.debian.org/doc/manuals/developers-reference/ch05.en.html#upload-stable
> 
>     Changing anything else in the package that isn't important is
>     discouraged, because even trivial fixes can cause bugs later on.

I don't think this section applies (5.5.1 Special case: uploads to the 
stable and oldstable distributions).  This section is talking about the 
few non-security reasons to update a package in stable:

    a truly critical functionality problem
    the package becomes uninstallable
    a released architecture lacks the package

In these cases, I agree, we should follow the same procedure as a 
security update and backport a minimal diff.

However, this isn't one of those cases.  This is a case not documented in 
the developer reference (yet?  elsewhere?), which is stable updates of 
the formerly-"volatile" things like spam and virus scanners, timezone 
updates, web scrapers/video downloaders, etc.

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.

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.

> > We 
> > don't backport functionality to old versions of ClamAV or SpamAssassin - 
> > this would seem to be the same thing.
> 
> 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.

In this case, the changes are the _only changes in the package_, as its 
_sole purpose is identifying credit cards_.

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.

> > The sole purpose of libbusiness-creditcard-perl is to validate and 
> > identify credit cards.  Credit card issues are updating these rules and 
> > issuing new credit cards with new number ranges without regard to our 
> > release cycles.  We should be able to update this module through -updates 
> > like we do ClamAV, Spamassassin, timezones and so forth.
> 
> 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.

0.35  Tue Feb  9 14:43:38 PST 2016
        - Fix bug identifying 49* Visa cards introduced in 0.34, patch from
          Ed J, thanks!
        - doc: Clarify processing agreements don't apply to Canada

0.34  Fri Feb  5 07:24:00 PST 2016
        - 19 digit Visa and Discover cards
        - MasterCard 222100-272099 range
        - Canada does not process JCB 3529-3589 as Discover, but Puerto Rico,
          US Virgin Islans, Northern Mariana Islands, Palau and Guam do
        - China Union Pay only processed as Discover in the US, Mexico and
          the Caribbean, not elsewhere outside China
        - 14 digit Discover remain only in 36*
        - receipt_cardtype subroutine supporting Discover's new receipt
          requirements

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.

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".

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.).

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 the enlightening discussion and all of your hard work on the 
Debian Perl team.

-- 
Ivan Kohler
President and Head Geek, Freeside Internet Services, Inc.  http://freeside.biz/
Debian GNU/Linux developer  |  CPAN author  |  cat person  |  ski addict