[development] Drupal's CVS policies... including 'foriegn' codein TinyMCE module?

[Wim Leers]

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
>
>