[hm] [wiki] 1er paso, actualizar

Dom Oct 18 12:44:47 CEST 2009

acabo de proponer un grupo de trabajo en sd para poder llevar estos
cambios adelante, no s�lo afecta al wiki del hackmeeting sino tambi�n a
otros mediawiki operativos en SD que se beneficiar�an mucho de estos
cambios. Os mantendr� al tanto, ir� un poco lento pero tampoco creo que
sea nada urgente. De hecho si miramos a los hist�ricos de ediciones del
wiki, durante el a�o no hay casi cambios hasta justo antes y despu�s del
HM.  de todas formas vamos a estudiarlo con la mayor prioridad posible.

saludos y gracias por listas las especificaciones, es muy �til.

xabier

david wrote:
> [1.] 
> Hola; creo que en el wiki se puede trabajar con tranquilidad sin esperar
> a que se acerque el pr�ximo hackmeeting.
> 
> [2.]
> Como ya se dijo el primer paso es actualizar versi�n e instalar algunas
> extensiones.
> 
> [3.]
> Para actualizar versi�n el servidor tiene que cumplir los requisitos.
> Ahora no los cumple.
> 
> Alguien dijo que hablar�a de esto en la asamblea de sindominio. ->
> [Comunicar respuesta a esta lista!]
> 
> Habr�a una opci�n provisional: �l se ofreci� a abrir un servidor virtual
> en los servidores de BlogxPopuli d�nde trabajar con un clon del wiki si
> se demora la decisi�n de sindominio. -> [opci�n a decidir!]
> 
> [4.]
> La soluci�n que se adopte en el servidor tiene que ser lo
> suficientemente flexible para que dentro de un tiempo no estemos en la
> misma situaci�n que estamos ahora.
> 
> Tenemos que:
> - poder actualizar a nuevas versiones de MediaWiki
> - Instalar las extensiones que sean necesarias en cada momento
> - Poder configurar el wiki desde "Localsettings.php"
> 
> Si 'sindominio' quiere una opci�n de gesti�n unificada de los MediaWikis
> (que me parece muy razonable) lo que tendr�a que hacer es crear una
> "wikifarm" como ya dijo Blackhold.
> La idea es que la actualizaci�n del c�digo base de MediaWiki se haga una
> sola vez y de forma centralizada para todos los wikis del servidor. Pero
> que la gesti�n de algunos aspectos sea personalizada de cada proyecto.
> Concretamente tienen que ser gestionadas aut�nomamente:
> - La configuraci�n de "Localsettings.php" de cada wiki
> - Las carpetas "extensions", "images" y "skins" de cada wiki
> 
> Blackhold me dijo que ha escrito un script para wikifarms de MediaWiki
> que bajo este modelo de gesti�n que he descrito a�ade un nuevo wiki
> cuando se ejecuta. Dijo que ten�a la idea de hacerlo a�n m�s f�cil de
> gestionar pasando el script a PHP.
> �l tambi�n tiene resuelta una soluci�n similar para los wikis de
> Blogxpopuli.
> Tenemos pues la soluci�n t�cnica disponible para hacer una wikifarm.
> 
> -> [transmitir necesidades a la asamblea de sindominio!]
> -> [comunicar respuesta/decisi�n a esta lista]
> 
> [5.]
> Tendr�amos que contar con el compromiso de 'sindominio' de no abandonar
> la actualizaci�n regular de "Mediawiki" a su �ltima versi�n estable.
> Esto implica, claro, actualizar si es necesario los requerimientos de
> servidor (PHP, MySQL, Apache, ...�?).
> 
> Si no fuera posible este compromiso la �nica soluci�n que veo es la que
> plante� �l en la asamblea: que dispongamos de un servidor virtual para
> el Hackmeeting y as� poder actualizar los requerimientos. Esta ser�a
> pues una opci�n distinta a la wikifarm.
> 
> -> [transmitir opciones/propuestas a la asamblea de sindominio!]
> -> [comunicar respuesta/decisi�n a esta lista]
> 
> [6.]
> Si se opta por la wikifarm estar�a bien centralizar los contenidos de
> im�genes y otros archivos subidos al wiki para no duplicar en varios
> proyectos y optimizar el uso de recursos. 
> Ser�a cuesti�n de tener un solo wiki para publicar archivos
> ("sd-wikicommons") que se muestran en los dem�s.
> Esta es la soluci�n de Wikimedia con el wiki
> "wikicommons" (commons.wikimedia.org) d�nde publican las im�genes de
> todas las wikipedias.
> �l tambi�n tiene esto resuelto en los wikis de BlogxPopuli. Se podr�a
> adoptar la misma soluci�n en la wikifarm de 'sindominio'
> 
> -> [transmitir propuesta a la asamblea de sindominio!]
> -> [comunicar respuesta/decisi�n a esta lista]
> 
> [7.]
> En la l�nea de lo que se habl� de usar extensiones sem�nticas y de
> formularios en el wiki del HM... yo optar�a por tener todo el paquete
> sem�ntico ("semantic-bundle") disponible y activar al menos las
> extensiones:
> - Semantic MediaWiki
> - Semantic Forms
> - Semantic Drilldown
> ...adem�s de otras extensiones incluidas en el mismo paquete pero que no
> son estrictamente "sem�nticas":
> - ParserFunctions
> - Widgets
> - Header Tabs
> 
> Mantener adem�s un Captcha y estar abierto a otras extensiones que
> puedan ser �tiles.
> 
> 
> 
> Otra vez ha sido una buena experiencia compartir el hackmeeting con
> todos/as vosotros/as.
> Por f�n hubo diversidad de colores en las camisetas y en vez de
> oscurecerse el grupo se coloreaba :-)
> L�stima que algunos fuerais tan reticientes a dejaros entrevistar para
> "HKp", de todas formas vamos a insistir y a algunos os vamos a
> perseguir :-)
> Una pena lo de los robos, a ver si se puede llegar a cubrir. Habr� que
> mejorar ese bug, tanta seguridad inform�tica tendr�a que inspirar alg�n
> sistema de seguridad anal�gica para estos temas.
> Me dej� una regleta (lleva mi e-mail escrita en rojo) en la sala ODS.
> Que quede para el Patio o el Hamlab.
> 
> 
> Un abrazo.
> 
> - David
> - dvdgmz
> 
> _______________________________________________
> HackMeeting mailing list
> HackMeeting en listas.sindominio.net
> https://listas.sindominio.net/mailman/listinfo/hackmeeting
> 

-- 
wget -O - http://sindominio.net/~xabier/xabier.gpg.asc | gpg --import

                   xabier BARANDIARAN   |  http://www.barandiaran.net
                   hamlab HACKLAB       |  http://hamlab.hacklabs.org

"There is no need for fear or hope, but only to look for new weapons"
                                                              DELEUZE