On May 25, 2007, at 2:35 AM, Gerhard Killesreiter wrote:
As I see it it would be sufficient to host the changed config files in our CVS. Everything else could be taken care of by advanced packaging scripts.
in the abstract, this is true. in reality, this is a nightmare, as i've already explained. the plumbing already exists to make projects and release nodes for 3rd party libraries, have proper dependencies, notifications when you need to upgrade, a way to share the same library among N drupal modules, etc, etc. the relatively weak "security" argument has been effectively refuted, IMHO. there's really not that much of a size/ performance cost from the CVS back-end side of things, either. the only thing standing between the people who want to leverage this functionality to make drupal easier to install and use is our own insistence on a policy that's only partially enforced anyway. some people are already ignoring this policy and getting the nice benefits right now. if we embraced this reality for some reasonable cases, others could do it tomorrow. in contrast, the code to get the packaging script smart enough to solve this problem will take many hours, lots of testing, a *major* friggin' security audit, a whole new level of complication for maintainers to learn, and a potentially vastly scarier thing for the CVS admins to have to monitor and audit ("just exactly where are you pointing the d.o packaging script to download sources from, random contrib maintainer?"). at least when the code is in our repo, it's easy to see what it is. if all that's in the repo is a URL to some tarball somewhere on the web, the potential for trojans, human error, transient site failures, etc, are all *much* higher. true, a malicious contrib maintainer could still put anything bad in their contrib they want, but at least we *could* audit that. if they just point to a reasonable looking URL, it'd be that much harder for us to see what's actually happening (sure, we could untar the packaged releases and inspect those, but we already don't have the resources to audit the commits to the repo as they're coming in -- we're certainly not going to start regularly auditing all the packaged tarballs). furthermore, they might point to a valid URL, but that other site might be compromised and sending out trojan'ed tarballs, which d.o would be happily downloading and packaging. :( in addition to fetching a tarball from a URL, we'd have to worry about at least an svn client to fetch with, if not git and others, along with cvs. plus, how would the maintainer specify how to unpackage the thing we download, where to put it, how to apply patches, move customized config files into the right places, etc, etc, without effectively giving everyone with a CVS account to our contrib repo shell access on the d.o servers? we'd have to basically hard-code a bunch of potential shell actions in some very restrictive sandbox and hope a) we got it all right and b) made it all flexible enough for people to use. it would be at least weeks, if not months (depending on who actually steps up to help write the code and how much funding is raised to sponsor their/our/my labor) before it was in a state that could be deployed for real on d.o. and, then it'd be a whole new full-time (unpaid) job for me to maintain it all, answer the endless stream of questions when people don't read the docs i'd have to spend hours writing, etc, etc. no thanks. killes: if you were going to be the one to solve all these problems and write this uber packaging script, all the docs, and maintain it forever, i'd be more sympathetic to your strict position on the philosophical right vs. wrong of committing 3rd party code into our contrib repo. however, i'm 95% sure this is going to fall to my shoulders if its ever going to get done, and therefore, i'm quite opposed to the "let's just get dww to spend hundreds of hours solving this for us" implication of your reply. and, hypothetically, if we had hundreds of hours of my time and/or many thousands of dollars to spend sponsoring some infrastructure work, is this really the best use of that time/money? if there was no alternative, that'd be one thing. but in this case, the alternative is easy and simple: stop being so stubborn about a policy that lots of long-time contributors to the project (not just the WYSIWYG crowd and the occasional do-nothing complainers in this thread) are in favor of relaxing under certain conditions. i'll say it again: if this proposal for "smarter packaging scripts to fetch 3rd party code" were an issue in the project queue, i'd set to "won't fix" on sight. -derek p.s. no, i'm not sure about the "hundreds" of hours, that's just a wild guess. my estimates for how much time it would take to design, build, test, deploy, document, and support the release system were so wildly unrealistic and low (in drupal terms, i was young, stupid, and still optimistic back then), that i'm now jaded when considering how long such things actually take. p.p.s. no, i'm also not advocating everyone should check in every possible 3rd party thing no matter what. i still think we need some level of control on this, and weigh it on a case-by-case basis.