Closed (fixed)
Project:
Drupal.org Library Packaging Allowlist
Component:
Code
Priority:
Normal
Category:
Feature request
Assigned:
Reporter:
Created:
18 Nov 2013 at 07:01 UTC
Updated:
4 Dec 2013 at 21:10 UTC
Jump to comment: Most recent
Drupal core already include http://benalman.com/projects/jquery-bbq-plugin into 7.x by default with MIT/GPL dual license.
On the other hand, my new project twbs_jquery.make would like to download it from official site with latest version manually.
May someone give a hand for adding the following Regex into whitelist?
^https://github\.com/cowboy/jquery-bbq/.+$
P.S. The ^https://github\.com/hswong3i/jquery-bbq/.+$ is a patched version for jQuery 1.9+
Comments
Comment #1
kreynen commentedConfirming that all the code in the https://github.com/cowboy/jquery-bbq/ repo is MIT/GPLv2 and the download is 2.3MB.
After removing the https://github.com/hswong3i/jquery-bbq fork from the original request I consider this RBTC. Rather than approving multiple forks of the same code on Github, I think we should only approve the official repo ask the distribution developer to do any additional patching in their .make file. That makes it much more obvious that the specific distribution is using a modified version of a library and keep the job of reviewing the whitelist requests much more manageable.
Comment #2
hswong3i commentedUnderstand the recommendation and so a meta issue #2138761: [meta][jquery-bbq] Remove legacy browser support for jQuery >= 1.9. created for our own needs, and twbs_jquery.make updated as below:
P.S. Just would also like to highlight that jquery-bbq haven't been updated since 3 years ago (https://github.com/cowboy/jquery-bbq/commits/master), where numbers of pull request send out for this jQuery >= 1.9 issues (https://github.com/cowboy/jquery-bbq/pulls). Therefore I don't really think that reporting that to original author can get help about solving it "officially" ;-S
Comment #3
btopro commentedI think the concern is more so the idea of constantly supporting packaging of forks from different projects.
Comment #4
hswong3i commentedAs refer to #1, shall we just keep it simple stupid as below:
Where individual needs can handle as like as #2 solution?
Comment #5
btopro commentedLooks good to me; will let kreynen push forward since he had the original reservations til the previous comment was verified.
Comment #6
kreynen commentedhttps://drupal.org/node/2140359
Comment #7
hswong3i commentedThank you for prompt reply and update ;-)