Splitting this off from #779452: Whitelist for external dependencies and #594704: Allow packaged install profiles on d.o to pull in code from other sources + sites.
I believe we're pretty close to agreement on the policy. From the other issue, the current draft is:
---
For a library to be added to the whitelist, it must:
- Be requested via the http://drupal.org/project/issues/drupalorg_whitelist issue queue by a module or profile maintainer, and seconded (RTBC) by at least one other community member, and
- Be licensed under a GPL-compatible license listed here: http://www.gnu.org/licenses/license-list.html#GPLCompatibleLicenses
- If a PHP library, it must be compatible with the version of PHP supported by the current Drupal Core release. (i.e., no PHP4-only libraries.)
- Be in use by an active Drupal module or installation profile.
- Be less than 10mb compressed.
- Not be legally questionable or malicious.
A library may be removed from the whitelist if:
- The Security team
leaddeems that the library is not receiving proper security maintenance which poses a threat to drupal sites. - The maintainer of the library declares it to be deprecated and the whitelist maintainers deems it prudent to be removed.
It can be established that no current release of any profile on drupal.org uses or has used the library in the last 6 months. (not sure how feasible it is to track this, so maybe strike this point on the basis of practicality.)
The whitelist maintainer shall be nominated and confirmed by agreement of the drupal.org infrastructure team to serve until resignation, or removal by agreement of the infrastructure team. For these purposes, "agreement of the drupal.org infrastructure team" means effectively: "2 +1's from trusted folks, no objections for 2 weeks."
---
See also #1360460: Populate initial team of 3rd party packaging whitelist maintainers and #783186: Packaging: document whitelist
Thanks!
-Derek
Comments
Comment #0.0
dwwmoved questions around the initial team itself to #1360460
Comment #0.1
dwwfixed del tags
Comment #1
dwwSorry, the initial post was a bit confused since I forgot we already had #783186: Packaging: document whitelist open, and I decided to move the whole question of the initial team of whitelist maintainers to a separate issue: #1360460: Populate initial team of 3rd party packaging whitelist maintainers. The summary is now fixed. Re-titling to focus the scope on the main thing we need to do here: finalize the criteria and process.
Thanks,
-Derek
Comment #1.0
dwwupdated summary based on #783186
Comment #2
gregglesI removed the word "lead" from the security team part. The team+lead(s) can figure out how their decision process will work and this policy doesn't need to be explicit about that process.
Comment #3
gregglesImplicit in my comment is a +1 on everything else, but it's worth saying: +1 on the amended version ;)
Comment #4
killes@www.drop.org CreditAttribution: killes@www.drop.org commentedlooks great to me!
Comment #5
geerlingguy CreditAttribution: geerlingguy commentedI like this, see no problems (legally or otherwise, but I'm no lawyer)... I dare to RTBC, since it seems we have at least three +1s and no negative remarks.
Comment #6
Gerhard Killesreiter CreditAttribution: Gerhard Killesreiter commentedI think the voting part should be changed to "by agreement of the infra team" or something like that. We do neither have a proper infrastructure for holding elections nor do we have a proper definition for the electorate...
Comment #6.0
Gerhard Killesreiter CreditAttribution: Gerhard Killesreiter commentedno need to explicitly state the structure of the security team in this policy
Comment #7
skottler CreditAttribution: skottler commentedThis looks good to me. +1
Comment #8
geerlingguy CreditAttribution: geerlingguy commentedIt looks like the voting part was updated. I'm pretty happy with this, but I do think we could strike out:
As stated in the bullet, it wouldn't be very practicable. But we should probably think about how we're going to keep the list trimmed well in the future—projects do die quite often!
Comment #8.0
geerlingguy CreditAttribution: geerlingguy commenteds/majority vote/agreement/ since the infra team doesn't have clear membership or any mechanism to hold such votes.
Comment #9
geerlingguy CreditAttribution: geerlingguy commentedI added in "Be in use by an active Drupal module or installation profile.", mostly because some people may simply add a bunch of libraries they think would be useful, but would just clutter up the whitelist.
Comment #10
geerlingguy CreditAttribution: geerlingguy commentedShould probably have people look things over again before committing to the guidelines, since some things have changed since Dec. 22.
Comment #11
geerlingguy CreditAttribution: geerlingguy commentedJust pinging everyone subscribed... would someone like to RTBC so we can close out this issue and complete the packaging whitelist project page/guidelines?
We've been operating under these guidelines for a month, with no real problems or concerns raised.
Comment #12
dwwLooks fine to me. If/when we need to change them, we will. ;) So, are you going to document this or should I? Where were you going to put it?
Thanks!
-Derek
Comment #13
geerlingguy CreditAttribution: geerlingguy commentedI put the criteria for inclusion and removal on the Drupal.org distribution packaging requirements page (seems a good fit), and I've linked to it from the packaging whitelist project page.
Comment #14
dwwSweet, thanks!
Comment #15.0
(not verified) CreditAttribution: commentedAdded "Be in use by an active Drupal module or installation profile." and struck a line that should be removed.