Re: [development] Drupal's CVS policies... including 'foriegn' codein TinyMCE module?
This is mainly for Dries and Andy. The case by case approach seems to be a logical solution to this problem. And the modules that may request this are a very limited, so it goes without saying this won't bog someone down and make CVS admins' lives miserable. Can we agree on who should be contacted to negotiate inclusion of customized external code? That sounds much better than just going back and forth without really achieving an end result. On 5/26/07, Michael Hess <mlhess@umich.edu> wrote:
-Make the first module dependent on the second with clear instructions
about where to get it from. <http://tinymce.moxiecode.com/download.php>
TinyMCE,already does this for some other CMS's
On 5/26/07, Ashraf Amayreh <mistknight@gmail.com> wrote:
This is mainly for Dries and Andy.
The case by case approach seems to be a logical solution to this problem. And the modules that may request this are a very limited, so it goes without saying this won't bog someone down and make CVS admins' lives miserable.
Can we agree on who should be contacted to negotiate inclusion of customized external code? That sounds much better than just going back and forth without really achieving an end result.
The infrastructure / CVS list would be the logical places. Gerhard tends to be the main guardian of our CVS repo. Having the discussion in private won't make the decision any better...if you read Gerhard's response, he's pretty clear on status. Most of the rest of this thread was talking about various solutions at the "wouldn't it be cool if..." stage. A patch to the project module / packaging scripts and/or an architecture doc on how such a thing would be built would be more useful. -- Boris Mann Office 604-682-2889 Skype borismann http://www.bryght.com
On May 26, 2007, at 9:29 PM, Boris Mann wrote:
A patch to the project module / packaging scripts and/or an architecture doc on how such a thing would be built would be more useful.
(trying not to lose my temper...) WTF? are you people not getting or not reading my messages? Gerhard seems to have completely ignored my input on the discussion, and now you are, too... how many times do i have to say it? 1) our existing policy is too strict, and should be relaxed under some circumstances. 2) it would require a *MASSIVE* (wasted) effort to try to solve this problem via modifying our packaging script. please RTF previous email of mine for details. i will *NOT* accept patches that attempt to do this. "won't fix" on sight... so, of all the many ways i've asked for help on project*, please do not try to "help" by working on such a patch. ;) also, given how much time and energy i've spent on the care and feeding of our CVS repositories, i wish i was at least being taken seriously enough that people read what i'm saying about this topic, and respected my views enough to reply (even if you disagree, at least address the points i'm making)... thanks, -derek
I must say that I strongly agree with Derek. An attempt to summarize: 1) The current policy is unfriendly to both module maintainers and module users. 2) Strict rules simplify maintenance and avoid chaos. But in this case, that's not true: more chaos is created! 3) Packaging scripts would have their own (quite major) problems, so that's no solution either. Shouldn't that be enough to change the policy? It would mean less work for everybody involved: 1) The CVS guardians don't have to do anything more or less at all. 2) The additional files shouldn't affect CVS performance. 3) Module maintainers don't have to worry anymore about how to make the downloading and installing of foreign code as painless as possible, as it will be included in the module. 4) Module users wouldn't even have to know they're using foreign code. The added advantage is that (especially with the update_status module installed, which will be in D6 core) they will probably update more often than when they'd have to download the foreign code themselves. So this is more secure IMHO, not less. Of course this depends on the module maintainer. But a module doesn't have to rely on foreign code to be insecure, so this point still stands. Of course, only GPL'ed foreign code could be included. I hope this summary helps in making the necessary decisions. Wim On May 27, 2007, at 10:11 , Derek Wright wrote:
On May 26, 2007, at 9:29 PM, Boris Mann wrote:
A patch to the project module / packaging scripts and/or an architecture doc on how such a thing would be built would be more useful.
(trying not to lose my temper...)
WTF? are you people not getting or not reading my messages? Gerhard seems to have completely ignored my input on the discussion, and now you are, too...
how many times do i have to say it?
1) our existing policy is too strict, and should be relaxed under some circumstances.
2) it would require a *MASSIVE* (wasted) effort to try to solve this problem via modifying our packaging script. please RTF previous email of mine for details. i will *NOT* accept patches that attempt to do this. "won't fix" on sight...
so, of all the many ways i've asked for help on project*, please do not try to "help" by working on such a patch. ;)
also, given how much time and energy i've spent on the care and feeding of our CVS repositories, i wish i was at least being taken seriously enough that people read what i'm saying about this topic, and respected my views enough to reply (even if you disagree, at least address the points i'm making)...
thanks, -derek
Simple question.... what is stopping a change in policy? Is is just the number of extra hours the CVS maintainers will have to put in to maintaining CVS? - Matt On May 27, 2007, at 5:16 AM, Wim Leers wrote:
I must say that I strongly agree with Derek.
An attempt to summarize: 1) The current policy is unfriendly to both module maintainers and module users. 2) Strict rules simplify maintenance and avoid chaos. But in this case, that's not true: more chaos is created! 3) Packaging scripts would have their own (quite major) problems, so that's no solution either.
Shouldn't that be enough to change the policy? It would mean less work for everybody involved: 1) The CVS guardians don't have to do anything more or less at all. 2) The additional files shouldn't affect CVS performance. 3) Module maintainers don't have to worry anymore about how to make the downloading and installing of foreign code as painless as possible, as it will be included in the module. 4) Module users wouldn't even have to know they're using foreign code. The added advantage is that (especially with the update_status module installed, which will be in D6 core) they will probably update more often than when they'd have to download the foreign code themselves. So this is more secure IMHO, not less. Of course this depends on the module maintainer. But a module doesn't have to rely on foreign code to be insecure, so this point still stands.
Of course, only GPL'ed foreign code could be included.
I hope this summary helps in making the necessary decisions.
Wim
On May 27, 2007, at 10:11 , Derek Wright wrote:
On May 26, 2007, at 9:29 PM, Boris Mann wrote:
A patch to the project module / packaging scripts and/or an architecture doc on how such a thing would be built would be more useful.
(trying not to lose my temper...)
WTF? are you people not getting or not reading my messages? Gerhard seems to have completely ignored my input on the discussion, and now you are, too...
how many times do i have to say it?
1) our existing policy is too strict, and should be relaxed under some circumstances.
2) it would require a *MASSIVE* (wasted) effort to try to solve this problem via modifying our packaging script. please RTF previous email of mine for details. i will *NOT* accept patches that attempt to do this. "won't fix" on sight...
so, of all the many ways i've asked for help on project*, please do not try to "help" by working on such a patch. ;)
also, given how much time and energy i've spent on the care and feeding of our CVS repositories, i wish i was at least being taken seriously enough that people read what i'm saying about this topic, and respected my views enough to reply (even if you disagree, at least address the points i'm making)...
thanks, -derek
Quoting Derek Wright <drupal@dwwright.net>:
On May 26, 2007, at 9:29 PM, Boris Mann wrote:
A patch to the project module / packaging scripts and/or an architecture doc on how such a thing would be built would be more useful.
(trying not to lose my temper...)
WTF? are you people not getting or not reading my messages? Gerhard seems to have completely ignored my input on the discussion, and now you are, too...
how many times do i have to say it?
1) our existing policy is too strict, and should be relaxed under some circumstances.
Yes, I agree but I seem to be low life and my posts seem to go unresponded to as well. I've already stated that we need to allow third party code. Someone with respect and more clout should be able to get +2 votes for this idea.
2) it would require a *MASSIVE* (wasted) effort to try to solve this problem via modifying our packaging script. please RTF previous email of mine for details. i will *NOT* accept patches that attempt to do this. "won't fix" on sight...
Especially at the automated packaging level.
so, of all the many ways i've asked for help on project*, please do not try to "help" by working on such a patch. ;)
One of these days I'll get into the code of project but not possible anytime soon.
also, given how much time and energy i've spent on the care and feeding of our CVS repositories, i wish i was at least being taken seriously enough that people read what i'm saying about this topic, and respected my views enough to reply (even if you disagree, at least address the points i'm making)...
One point I made in response to one of the comments was to create a separate contrib/lib directory to hold the third party libraries. Then the modules would depend on lib/third_party and duplication of such libraries would be eliminated. Good luck in your quest to relax the policy. Earnie
+100 on this It is trivial to implement just change the policy (but add a pretty please permission somewhere in the process). -----Original Message----- From: development-bounces@drupal.org [mailto:development-bounces@drupal.org] On Behalf Of Derek Wright Sent: Sunday, May 27, 2007 4:12 AM To: development@drupal.org Subject: Re: [development] Drupal's CVS policies... including 'foriegn' codein TinyMCE module? On May 26, 2007, at 9:29 PM, Boris Mann wrote:
A patch to the project module / packaging scripts and/or an architecture doc on how such a thing would be built would be more useful.
(trying not to lose my temper...) WTF? are you people not getting or not reading my messages? Gerhard seems to have completely ignored my input on the discussion, and now you are, too... how many times do i have to say it? 1) our existing policy is too strict, and should be relaxed under some circumstances. 2) it would require a *MASSIVE* (wasted) effort to try to solve this problem via modifying our packaging script. please RTF previous email of mine for details. i will *NOT* accept patches that attempt to do this. "won't fix" on sight... so, of all the many ways i've asked for help on project*, please do not try to "help" by working on such a patch. ;) also, given how much time and energy i've spent on the care and feeding of our CVS repositories, i wish i was at least being taken seriously enough that people read what i'm saying about this topic, and respected my views enough to reply (even if you disagree, at least address the points i'm making)... thanks, -derek -- No virus found in this incoming message. Checked by AVG Free Edition. Version: 7.5.472 / Virus Database: 269.8.0/819 - Release Date: 5/26/2007 10:47 AM
Seems like module maintainers could just "officially" incorporate GPL code into their module, meaning they will support it (hopefully including contributing bug reports and patches "upstream"). Thus it's no longer "third-party code," it's part of the drupal module which they are maintaining. I wouldn't consider this "ideal".. but it would be a major task to build something like "drupal ports", where tarballs are downloaded from the vendor and then patch files are applied if necessary. speaking of which, it's interesting that on freebsd you can install drupal tinymce module from ports, http://www.freshports.org/www/drupal5-tinymce, which depends on tinymce http://www.freshports.org/www/tinymce (tinymce is downloaded from sourceforge if you "build" it), and symlinks the server-wide tinymce into the drupal module directory. I happen to use freebsd but hadn't given much thought about using it to manage the installation of drupal modules.. --mark On 5/27/07, Walt Daniels <wdlists@optonline.net> wrote:
+100 on this
It is trivial to implement just change the policy (but add a pretty please permission somewhere in the process).
-----Original Message----- From: development-bounces@drupal.org [mailto: development-bounces@drupal.org] On Behalf Of Derek Wright Sent: Sunday, May 27, 2007 4:12 AM To: development@drupal.org Subject: Re: [development] Drupal's CVS policies... including 'foriegn' codein TinyMCE module?
On May 26, 2007, at 9:29 PM, Boris Mann wrote:
A patch to the project module / packaging scripts and/or an architecture doc on how such a thing would be built would be more useful.
(trying not to lose my temper...)
WTF? are you people not getting or not reading my messages? Gerhard seems to have completely ignored my input on the discussion, and now you are, too...
how many times do i have to say it?
1) our existing policy is too strict, and should be relaxed under some circumstances.
2) it would require a *MASSIVE* (wasted) effort to try to solve this problem via modifying our packaging script. please RTF previous email of mine for details. i will *NOT* accept patches that attempt to do this. "won't fix" on sight...
so, of all the many ways i've asked for help on project*, please do not try to "help" by working on such a patch. ;)
also, given how much time and energy i've spent on the care and feeding of our CVS repositories, i wish i was at least being taken seriously enough that people read what i'm saying about this topic, and respected my views enough to reply (even if you disagree, at least address the points i'm making)...
thanks, -derek
-- No virus found in this incoming message. Checked by AVG Free Edition. Version: 7.5.472 / Virus Database: 269.8.0/819 - Release Date: 5/26/2007 10:47 AM
This reminds me how much I love FreeBSD. On May 28, 2007, at 10:06 PM, mark burdett wrote:
Seems like module maintainers could just "officially" incorporate GPL code into their module, meaning they will support it (hopefully including contributing bug reports and patches "upstream"). Thus it's no longer "third-party code," it's part of the drupal module which they are maintaining.
I wouldn't consider this "ideal".. but it would be a major task to build something like "drupal ports", where tarballs are downloaded from the vendor and then patch files are applied if necessary.
speaking of which, it's interesting that on freebsd you can install drupal tinymce module from ports, http://www.freshports.org/www/ drupal5-tinymce, which depends on tinymce http://www.freshports.org/ www/tinymce (tinymce is downloaded from sourceforge if you "build" it), and symlinks the server-wide tinymce into the drupal module directory. I happen to use freebsd but hadn't given much thought about using it to manage the installation of drupal modules..
--mark
On 5/27/07, Walt Daniels <wdlists@optonline.net> wrote: +100 on this
It is trivial to implement just change the policy (but add a pretty please permission somewhere in the process).
-----Original Message----- From: development-bounces@drupal.org [mailto:development- bounces@drupal.org] On Behalf Of Derek Wright Sent: Sunday, May 27, 2007 4:12 AM To: development@drupal.org Subject: Re: [development] Drupal's CVS policies... including 'foriegn' codein TinyMCE module?
On May 26, 2007, at 9:29 PM, Boris Mann wrote:
A patch to the project module / packaging scripts and/or an architecture doc on how such a thing would be built would be more useful.
(trying not to lose my temper...)
WTF? are you people not getting or not reading my messages? Gerhard seems to have completely ignored my input on the discussion, and now you are, too...
how many times do i have to say it?
1) our existing policy is too strict, and should be relaxed under some circumstances.
2) it would require a *MASSIVE* (wasted) effort to try to solve this problem via modifying our packaging script. please RTF previous email of mine for details. i will *NOT* accept patches that attempt to do this. "won't fix" on sight...
so, of all the many ways i've asked for help on project*, please do not try to "help" by working on such a patch. ;)
also, given how much time and energy i've spent on the care and feeding of our CVS repositories, i wish i was at least being taken seriously enough that people read what i'm saying about this topic, and respected my views enough to reply (even if you disagree, at least address the points i'm making)...
thanks, -derek
-- No virus found in this incoming message. Checked by AVG Free Edition. Version: 7.5.472 / Virus Database: 269.8.0/819 - Release Date: 5/26/2007 10:47 AM
participants (8)
-
Ashraf Amayreh -
Boris Mann -
Derek Wright -
Earnie Boyd -
mark burdett -
Matthew Farina -
Walt Daniels -
Wim Leers