Remove commit restrictions for installation profiles

Yup. Historically, the reason we did this is that we didn't want people to checkin entire copies of views and such to their install profile directories, which was tempting given how lame the previous system was for install profiles. Now that we have a sane packaging system, there's no reason to checkin other contrib code directly to your profile. But, it'd be really nice to allow profiles to define their own modules and themes if they need to, for the reasons alex_b explains here and at http://drupal.org/node/779440. So yeah, this one is pretty easy. All we need is to remove some restrictions in the CVS access control code and some documentation. I'm not sure if the release node form is the best place to do it (it's sort of too late at that point), but it's not obvious to me where these warnings should live...

Better title, since people keep opening other issues for basically the exact same thing, e.g. #831412: Allow images in installation profiles

Marking this fixed, since the technical issues with project no longer exist, we're pretty much settled on blowing away restrictions in the move to git, and there's little point in changing this before we actually make the vcs switch. (I hope...) Maybe a little premature, but this issue isn't likely to see much traffic otherwise...

Well, it obviously depends on when the switch will happen, because it limits profile development until then :|

Yeah, greggles pointed this out to me on IRC. Unmarking fixed, especially because it SEEMS like the fix for this is very, very trivial, and nothing stands in the way of doing it now.

Right. It will potentially be a while before we switch to Git, and meanwhile these restrictions are no longer needed (and causing some harm). This issue has been open long enough (and enough duplicates submitted) to give anyone else on the infra/CVS teams a chance to object. Seeing none, I went ahead and lifted the restrictions in the contributions/profiles directory. We're down to the general restrictions on packaged files, license*, and .(svn|bzr) directories. I committed the change to the xcvs-contrib.php config file to the private CVS repo and deployed on cvs.d.o.

YAY!

I posted http://groups.drupal.org/node/85194 to the http://groups.drupal.org/distribution-profiles group to inform interested parties. Folks should feel free to publicize in other ways as they see fit.

Currently we don't/can't track usage of installation profiles - http://drupal.org/project/usage/uberdrupal - does this change affect that? What about update module letting people know that a module is out of date if that module is placed inside a profile?

Currently we don't/can't track usage of installation profiles - http://drupal.org/project/usage/uberdrupal - does this change affect that?

Not directly, no. We should open a separate issue to discuss this I think. It's also related to #509398: Install profiles should be modules with full access to the Drupal API and all it entails(.install files, dependencies, update_x).

What about update module letting people know that a module is out of date if that module is placed inside a profile?

At first I thought you were asking about modules packaged with an install profile, and there are two ways "update status" handles that:

A) Update status itself on installed sites works fine to tell you if any real module projects are out of date, just like always
B) Project module on d.o gives you update-status-like info on release nodes of distributions, e.g.: http://drupal.org/node/869134

However, you're talking about the modules *committed* to the install profile directory directly (as per this issue). I actually don't know if that case is handled correctly by update status. It's possible that all the plumbing I put in place magically Just Works(tm) for this. Someone would have to test it. There *is* a release history feed, even for install profiles:

http://updates.drupal.org/release-history/uberdrupal/6.x

And, the packaging script does its .info file magic, even for install profiles. So, if a module is included in an install profile, the .info file *should* get the right meta data to point update_status at the above feed and in theory, it all works... At least the update_status part of it.

However, if the profile reports there's a newer version, it's not very easy it is to upgrade. :( I guess you can just re-download the whole package and install it in place. However, there's no equivalent to update.php to handle changes between versions of the profile. So, things that changed in .profile itself aren't going to be upgraded/reconfigured/reinstall and you'll be in a slightly weird state -- unless of course the profile maintainer goes out of their way to handle these cases in their profile's module's .install file with hook_update_N() implementations. This is part of what makes install profiles tricky. It's all sort of a can of worms.

I know this is closed, but...for the sake of completeness:

http://drupal.org/project/usage/hyperlocalnews shows that yes, it does count usage if you have a module inside a profile.

My admin/reports/updates page shows, however, that the update information for modules inside of profiles doesn't currently work.