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
signature.asc
Description: Digital Signature