Allow modules/themes not hosted on Drupal.org to be packaged into distribution .make files.

One reason this is important is that a situation I've run into is heavily patching a drupal module to the point that patches start conflicting with each other. When this happens I write a custom patch that will only work with my project and host it as a Gist on GitHub. I feel it would be pointless/noise to post this one off patch to a drupal.org issue queue stating "Here is a patch that is useless to everyone but me".

Technically it's not too bad. We've already got the whitelist plumbing on d.o and we could easily add another case inside drupalorg_drush to check the 'url' attribute for 'projects' against the whitelist, just like we do for 'libraries'. Other than that, the main thing that's not going to Just Work(tm) would be the display code when you're viewing a packaged distribution release to show you these externally hosted modules/themes. That's non-trivial, but certainly solvable.

But, it seems like a policy can of worms:

A) It's not always obvious what licenses features that live on feature servers have.

B) Feature servers appear to be more sprawling than individual external libraries. If we just whitelist 'code.devseed.com' (or whatever) then it's sort of a free-for-all. However, we obviously don't want to get into separate whitelist entries for every feature on the server.

C) Seems like we want to encourage features being used in distros to just be hosted on d.o.

Anyway, I'm torn. If the greater We(tm) think this is a good idea, it's not a horrible mess to implement, and some of the work is already done. But, I'm reluctant to spend time on it without more clarity on the policy concerns I raised.

Thanks,
-Derek

p.s. @langworthy: totally different issue. This is about 'url' for 'projects' e.g. modules hosted on feature servers. You're talking about allowing external patches. Please open a separate issue about that.

Since I maintain a distribution I thought I'd explain my rationale for not hosting certain projects on d.o.

Several of the features that I host on GitHub and pull into the distro do nothing more than capture configuration settings for things like content types and views. They don't introduce any new functionality, they just implement a specific use case by building on existing tools. Someone might like to build and maintain an Events Calendar feature, as I do, but prefer to display six events in the block display of the events view, instead of four. I didn't think hosting separate projects for these nominally different configurations would be a sensible use of d.o resources and namespace. My "Defaults" feature, also on GitHub, captures even more obscure and arbitrary stuff like per-nodetype settings for comment, nodeblock, page_title, xmlsitemap and so on.

For me anyway, features have become a nifty way to take some of the traditional configuration steps involved in site implementation, and automate them. Maybe I'm doing it wrong and all this stuff belongs in the install profile. But it's much easier to maintain as a feature. Anyway, lots of individuals who build Drupal sites have their own preconceptions of what those traditional configuration steps are. The number of people using features to capture those individual preferences seems likely to increase. As someone suggested, putting them all on d.o seems like it would just add a lot of noise.

You can commit such features (as features) directly to the Git repo for your install profile. If they're totally specific to your distro, just include them directly. See https://drupal.org/node/642116#commit -- you're free to manage all this configuration using features instead of trying to put it all directly into the .profile, but you can still just manage all that code directly on git.d.o (without the hassle of maintaining separate projects for things that are only useful in the context of your distro).

This doesn't work so well if you want to share the same feature across multiple distros, but in that case, it probably is something worthy of just being a project on d.o (maybe other people will want to use it, too).

@dww:

If they're totally specific to your distro, just include them directly.

Thanks, that's exactly what I'll do with my Defaults feature.

if you want to share the same feature across multiple distros ... it probably is something worthy of just being a project on d.o (maybe other people will want to use it, too)

That does apply to a few of the custom features in this distro, but essentially they are still just implementation details. This diagram from this post illustrates the mental model I'm working with here. Our custom implementations of an Image Gallery or Location or whatever are a whole level of abstraction up from the core and contrib modules they're built upon. I assumed this meant that they don't belong on d.o. But I guess I'm hearing that as long as they are reusable, this is where they ought to live.

One of the custom features in this distro is an image rotator. I recall this being the classic example of the "bajillion modules on d.o that all do the same thing" problem. Is this no longer broadly discouraged?

I'm currently in Denver and would love to continue talking about this in person :]

Bumping this one. I'm working on a distribution that's going to be drawing resources in from a few external places. It almost seems like an arbitrary restriction and very much "if you don't host it all on d.o we won't build your makefile"

While I agree with @webchick the Drupal projects belong on Drupal.org, the current process and blacklog in the Project Review was too disruptive to get work done efficiently when it involved new contributors. Spending 3-4 months for a non-vetted user to get a "feature package" promoted so it can be packaged and included in a distribution didn't meet our needs. Going through that 3-4 month process doesn't even result in the user being able to create the next feature package as a full project. They would have to spend another 3-4 months! Beacuse of this, we gave up on using Drupal.org for feature based contribution from new contributors. We moved the projects to GitHub and whitelisted them (#2316955: Please Whitelist cm_starters project) so they can be included in a distribution.

While some of the feedback I've provided in the past about the tiered/caste system of Drupal contrib is now included in #2453587: [policy, no patch] Changes to the project application review process, until that is actually implemented we will continue to host projects we want a non-vetted user to manage on GitHub.

@typhonius If you request a project be whitelisted, as long as it meets all of the licensing and size restrictions, it will be approved regardless of whether it includes Drupal module or theme code.

Drush make is no longer maintained, and is only useful For Drupal-7-based distributions, so we shouldn’t add any more functionality for it.