Without getting into the details, I've run into some issues with the current project review process and how that group controls the vetted git user permission and promoting projects since the D7 upgrade of Drupal.org. The current process and policies are hindering my ability to collaborate effectively on Drupal.org. I am considering moving a large part of a project to GitHub. Hopefully it won't come to that, but while considering this I realized a modules on GitHub can meet all the criteria to be whitelisted.

https://www.drupal.org/node/1475972#whitelist-criteria

Be requested by a module or profile maintainer, and seconded (RTBC) by at least one other community member - CHECK
Be licensed under a GPLv2 compatible license - CHECK
Must be compatible with the version of PHP supported by the current Drupal Core release - CHECK
Be in use by an active Drupal module or installation profile - CHECK
Be less than 10MB compressed - CHECK
Not be legally questionable or malicious - CHECK

Once whitelisted, I could add the module to the .make of a distribution. The module would be placed into the modules directory during packaging. The distribution user would be oblivious to that fact that the module came from GitHub.

I realize there are issues like versioning and issues queues, but I actually think those are easier to overcome than the issues with the project review process.

Has anyone requested a module or theme be whitelisted? Would we approve them if they did?

Comments

kreynen’s picture

kreynen commented
Related issues: +#2315231: [D7] Community Media Starter
kreynen’s picture

kreynen commented
Title: Whitelisting Drupal modules and themes hosted on GitHub? » Please Whitelist cm_starters project

Now that the project review team has officially refused to promote a project that contains only Feature exports that we need in a distribution, I'm changing this from a general "what if" scenario to a specific request. Before the D7 upgrade of Drupal.org, any user with the permission to create full projects could promote any project if they were added as a co-maintainer. It didn't matter if the owner of the project node had the permission to create full projects or not. Now a small group who put more emphasis on whitespace and line length than collaboration controls the only method for users who don't already have the permission to promote projects from sandboxes to full project.

There are at least 3 potential workarounds are:

  1. permissioned users creates a project, adds the non-permissioned user as a co-maintainer, and (optionally) request that ownership of the project be given to the other user
  2. add the feature exports directly to the distribution
  3. move the work to GitHub, whitelist the project, add the project to the distribution

The first 2 options only work for me because I already have the permission to create full projects. The second option works for everyone.

Our specific reason for not being able to use Drupal.org to host the feature export has to due with the project node ownership and our desire to have a distributed, collaborative ownership of our distributions, but it really shouldn't matter why someone wants to use GitHub over Drupal.org to host their project's repository. Maybe they prefer pull requests to patches. It doesn't really matter if the project meets all the whitelist criteria.

So please whitelist https://github.com/cmdrop/cm_starters
The license is GPLv2 https://github.com/cmdrop/cm_starters/blob/master/LICENSE
The compressed download is ~ 14k
It is the primary repo for the project and does not contain libraries, assets, or code with any other license.

btopro’s picture

btopro commented
Status: Active » Reviewed & tested by the community

meets whitelist requirements, is a sad state of affairs but totally understand.

Could you supply a proposed whitelist entry

kreynen’s picture

kreynen commented

For GitHub, we shouldn't rely on the user to provide the pattern. When reviewing the GitHub entries, I found way too many entries that looked like https://www.drupal.org/node/1466244#comment-9017049.

Use the pattern in https://www.drupal.org/node/2295977

While I think the project review process has lost its way, I did find things in https://www.drupal.org/node/894256 we could borrow for the whitelist documentation. Right or wrong, the project review process is well documented and the maintainers stick to the process they've documented.

geerlingguy’s picture

geerlingguy commented
Status: Reviewed & tested by the community » Fixed

Fixed: https://www.drupal.org/node/2320603 (is the first entry, ^(git|https|http)://github\.com/cmdrop/cm_starters[.git/].+$, correct?).

David_Rothstein’s picture

David_Rothstein commented

I don't see a problem with whitelisting Drupal-specific code on GitHub if someone really wants to, but the reasons stated in this particular case (for not using drupal.org) don't look fully accurate to me so for the purpose of correcting the record and for others who might consider this in the future:

Now that the project review team has officially refused to promote a project that contains only Feature exports that we need in a distribution

I assume this refers to the related issue #2315231: [D7] Community Media Starter but I read through that and that's not what happened at all - actually the opposite happened. They specifically offered to promote the project, but the issue was then closed without responding to the offer.

Before the D7 upgrade of Drupal.org, any user with the permission to create full projects could promote any project if they were added as a co-maintainer. It didn't matter if the owner of the project node had the permission to create full projects or not.

As described I agree that makes no sense, but isn't that just a bug introduced in the D7 upgrade that can/should be fixed?

In short, if someone really wants to host their Drupal code on GitHub and use it in projects on drupal.org I don't see any reason to prevent that, but they should consider if it's really worth it... the project misses out on Update Status notifications, security team coverage (granted less likely to matter for a Features export), etc., that you get if it's hosted on drupal.org.

Status: Fixed » Closed (fixed)

Automatically closed - issue fixed for 2 weeks with no activity.