[Imc-drupal-dev] relaunch ourselves: all/modules

jonhattan jonhattan at faita.net
Wed Dec 5 03:07:30 PST 2007


Bruno De Bondt escribió:
> jonhattan wrote:
>   
>> mark burdett escribió:
>>   
>>     
>>> Hi, i still depend on svn or other scm for all my projects, 
>>> but, the drupal infrastructure could suit us quite well for maintaining 
>>> a large number of sites: the update_status module will tell you if your 
>>> modules are out of date, and prompt you to upgrade. 
>>>     
>>>       
>> Yes, update_status is very useful, but it only handles releases as 
>> 5.x-x-x. Some maintainers recommend you to use the -dev tarball, that 
>> can't be handled by update_status.
>>
>> Perhaps I've been misunderstood. Although update_status tell you about 
>> current versions, you still have to manually download, untar and do 
>> update.php. I propose to download & untar in a shared folder and any imc 
>> could update it's modules just downloading (ftp, svn up,...) this shared 
>> folder to her server.
>>   
>>     
>
> Perhaps the CVS deploy module could help (http://drupal.org/node/151342)
> ? Haven't used it myself though.
>
> -- bruno
>   

Hi Bruno, list:

I've been reading along cvs_deploy and update status. I've found that 
update status is in drupal 6 core, so It should be a way to go for us.
With cvs deploy, update status is cvs-aware, useful if you got the 
modules from drupal cvs, not useful AFAIHS (as far as i have seen :P) if 
getting the -dev instead of an official package.

I've also found drush[1], the drupal shell. I've found it very useful to 
manage site packages and to deploy/update remote sites. As an example:

# drush pm install views (install the views module)
# drush pm refresh (same as refreshing the update_status via web)
# drush pm update (the update_status list of modules, current and 
available version)
# drush pm update views (only update views module)
# drush sync user at remote:path (copy the entire drupal folder or parts to 
remote)
# drush cron (exec cron)
# drush cache clear

there're some other actions related to sql and the watchdog.


[1] http://drupal.org/project/drush






>
>
>   
>> We also have specific patches for indymedia, such as the ones involved 
>> with "hidden" contents or anonymization, that could be applied in that 
>> shared folder.
>>
>>   
>>     
>>>  meanwhile, install 
>>> profiles will soon be available for download as tarballs which include
>>> all required modules.
>>>   
>>>     
>>>       
>> are you talking about drupal or indymedia?
>> if about drupal, is there a way to automagically generate a profile or 
>> must we go through
>> http://drupal.org/node/67921 ?
>> if about indymedia, what are all required modules? :P
>>
>>   
>>     
>>> it seems ideal to use (and contribute to) drupal.org infrastructure 
>>> rather than building parallel systems.
>>>   
>>>     
>>>       
>> My proposal doesn't need to drop a line of code, is a way to manage 
>> existing code updating. It's made by hand, no automation, but it's made 
>> once and no as many times as drupal imc's there be.
>>
>> Anyway, I'm doing imc-canarias drupal in theese days, adding all the doc 
>> to  ImcDrupalDev, and my all/modules will be shared for those wo don't 
>> want to go through downloading and untaring a bunch of modules.
>>
>>
>> jonhattan
>>
>>   
>>     
>>> --mark
>>>
>>> On Sun, 02 Dec 2007 21:37:17 +0000, jonhattan wrote:
>>>   
>>>     
>>>       
>>>> Hi all,
>>>>
>>>> time by time a new drupal indysite is launched, each one is built from 
>>>> scratch.
>>>> We still haven't a comprehensive list of modules nor a installation 
>>>> profile, but a lot of individual efforts on commenting it's own work on 
>>>> a external wiki or blog. It's good to have the work documented, it's 
>>>> better to merge (not group ;)) documentation in a common place: 
>>>> ImcDrupalDev.
>>>>
>>>> I think a common project that can sum our disperse efforts could be to 
>>>> complete the modules list [1] with all modules that can be part of a 
>>>> common indysite instance. We know drupal has tons of modules, let's 
>>>> select the key ones.
>>>> Also I think it will be very useful to have a "shared folder" (sorry my 
>>>> MS expression :P) to put the last version of modules. This shared folder 
>>>> could be a repository, collaborative managed and providing an easy 
>>>> method to update local imc's via a simple svn/cvs/.. update. Instead of 
>>>> each one manually updating 20+ modules on own servers, let's share the 
>>>> effort.
>>>>
>>>>
>>>>
>>>> [1] https://docs.indymedia.org/view/Devel/ImcDrupalDevModules
>>>>
>>>>
>>>> jonhattan,
>>>> imc-canarias
>>>> _______________________________________________
>>>> Imc-drupal-dev mailing list
>>>> Info: https://docs.indymedia.org/view/Devel/ImcDrupalDev
>>>> Imc-drupal-dev at lists.indymedia.org
>>>> http://lists.indymedia.org/mailman/listinfo/imc-drupal-dev
>>>>     
>>>>       
>>>>         
>>>   
>>>     
>>>       
>> _______________________________________________
>> Imc-drupal-dev mailing list
>> Info: https://docs.indymedia.org/view/Devel/ImcDrupalDev
>> Imc-drupal-dev at lists.indymedia.org
>> http://lists.indymedia.org/mailman/listinfo/imc-drupal-dev
>>
>>   
>>     
>
>   



More information about the Imc-drupal-dev mailing list