Voting starts in March for the Drupal Association Board election.
Can we include third-party code, libraries, or datasets in CVS?
Recently I suggested pulling various jQuery libraries into a common module to avoid having them included multiple times in different modules' CVS directories, http://groups.drupal.org/node/2787. Gerhard informed me quite appropriately that we restrict third party code in CVS.
Now that I look, I find this is what we say in the Drupal CVS contributions README:
"In cases where another non-Drupal project is required DO NOT include that code in the repository. Instead provide a link where the other code can be downloaded and instructions on how to install it."
I could and presumably should delete the jQuery and other external code I have in my modules. But doing so personally won't address the general issue. I'd like first to discuss the issue and see if we can find some solutions.
The main thing is, it's not always so easy as "provide a link". External code is not necessarily available for easy download in the same form over an extended period. Taking jQuery libraries as an example, a single Drupal module might require jQuery libraries from 4 or more different locations, scattered over several private websites, readily available only in current versions (potentially incompatible with a particular version of Drupal core). The necessity of hunting down compatible versions from e.g. SVN repositories would effectively lock out most module users.
Dries in a thread on GPL code in CVS said last May :
"We've also decided against mirroring other projects in our CVS repositories -- unless there are good reasons to do so."
What would such "good reasons" be? Can we come up with guidelines that allow us to include certain types of external libraries, without contributing substantively to code bloat, or putting undue demands on our volunteer CVS maintainers?
Here are several potential approaches to third party code:
- Produce and follow guidelines that permit limited inclusion of third party code in CVS.
Here are some suggestions, based on what I imagine the reasons are for including jQuery in core:
- It's small (how small is small? <30kb?)
- It's GPL.
- We need to support a particular version for a relatively long period, but that version may not be readily downloadable for that whole period (without resorting to methods beyond the typical user's expertise, e.g., checking out from a versioning system).
Other potential reasons might include:
- Need to patch the external files.
If they were clearly communicated, these guidelines might help prevent some of the externally produced code that currently contributes the most to CVS bloat (e.g., external databases several megabites in size).
- Introduce an application process, where individual module developers may apply for permission to include a particular external library.
- Combine 1 and 2: we have guidelines, and if you feel you meet the guidelines you can apply. No external code allowed without explicit permission.
- Create a non-CVS drupal.org repository where module developers can place external code could for download. Users are instructed to download separately from there.
- Introduce a way for our packaging scripts to include externally-hosted files.
- Clarify and enforce a "no third party code" rule and delete a lot of code from many existing modules. IMO, this approach only makes sense if we have the will and ability to educate about and ultimately enforce a "no third party code" rule.
There's no approach that's going to please everyone. I think options 1 or 3 might be an improvement over what we have now. Comments?