2008/10/1 Carlos Javier Borroto <[EMAIL PROTECTED]>: > 2008/10/1 Olemis Lang <[EMAIL PROTECTED]>: >> 2008/9/30 Maykel Moya <[EMAIL PROTECTED]>: >>> Olemis, es simple: Trac _no es_ un sistema multiproyecto. No importa si >>> un tipo le hizo un plugin. >> >> Error... tengo un Trac en mi casa donde hosteo los seis proyectos más >> malévolos con los que pretendo extender mis planes de dominación >> mundial... En cuanto lo logre Ud van a saber lo que es bueno :D ... >> por supuesto que esto es una broma... >> >> Por fvr *no pienso hablar más acerca de esto* después de esta vez... >> no es nada de plugins, nada de eso... les hablo de *tracd* el servidor >> standalone de Trac... cómo es posible que no comprendan eso ? Nada de >> plugins, cero plugin... >> >
Me convencieron... creo que tienen preocupacion suficiente (y base para estar preocupados) así que hablemos un poquito más al respecto > Olemis disculpa si no es el caso, pero creo que estás cayendo en el > error de subestimar con quienes debates, en mi vida he usado trac, o > ningún otro software de gestión de proyectos, siquiera he usado un > simple software para control de versiones, porque descargame alguna > que otra fuente de un software utilizando 'svn co' o 'hg' Estoy de acuerdo con esto... y soy de los que defiende que nadie se las sabe todas... pero en muchos casos hay opiniones que surgen de no estar familiarizados con el uso de las apps > pues no > cuenta en mi opinión, pero aún así creo ser capaz de darme cuenta que > el problema aquí es claramente que tu entiendes por 'multiproyecto' lo > que entienden Moya y Servilio. Y no es que estés equivocado en sí, es > que aquí se está utilizando multiproyecto para definir algo más amplio > de lo que tu pareces entender y simplemente te has ido por la tangente > de como tu único argumento en favor de trac, que si es multiproyecto. > Ya veo algo de «donde dije digo digo Diego»... ok > Como yo lo veo lo y al ver que mencionas opensvn.csie.org y como es de > esperar conoces sourceforge.net, pues te va a ser fácil entender, lo > que se quiere es algo a lo sourceforge.net y no un simple > opensvn.csie.org. > Si te llegas al segundo, veras que ni siquiera tiene > la opción de buscar entre los proyectos que hospeda, Claro... Capto la idea... También soy consciente de que opensvn.csie.org tiene estos inconvenientes... y los he sufrido en carne propia (los que yo he creado y mantengo están en SF.net). Antes de seguir IMO SF.net no debería ser «la idea a seguir», o dicho de otra forma ... una «idea a seguir» que considero más apropiada es la de Google Code... De hecho yo hosteaba los prjs ahí hasta que limitaron el acceso a las descargas y el wiki y ... y ... y me moví a SF.net Vamos a hacer un repaso de los servicios que tiene SF.net (lo estoy mirando ahora, pero si me falta alguno por favor no duden en preguntar) para ver lo que se puede hacer ya con Trac + SVN y lo que habría que desarrollar. - Wiki + Web... todo lo de las wiki de SF.net lo tiene Trac, excepto estadísticas de acceso (esto es general a no ser mediante el uso de un plugin que creo que existe habría que mirar bien, pero en mi opinión las estadísticas es algo decorativo en etapas tempranas del sitio... lo importante es los servicios que promuevan el desarrollo. Luego en el peor de los casos se puede hacer un alto «breve» para integrar otros srvc como lo ha hecho SF.net recientemente para migrar a sus nuevo datacenter) - Creación de proyectos ... a desarrollar ... pero no creo que sea difícil hacerlo con la ayuda de trac-admin + svnadmin ... De hecho yo creo mis prjs (Trac + SVN) utilizando un script sencillo que invoca a estos dos y podría adicionalmente editar las secciones de trac.ini que me hagan falta... me quito problemas de arriba. - Página personal, no hay... pero este servicio se puede complementar con un CMS o blogs etc... Por eso es que abogo por que esos estén hechos en Python, para facilitar la integración de los servicios en una etapa más avanzada si es que esto perdura, como todos queremos claro... - Noticias globales acerca de los projectos... Esto no lo hay «de fábrica», pero en el Trac tiene asociado un sistema de notificación que se puede reutilizar ... Mi idea... Hacer un projecto en el cual se cree un ticket por cada petición de creación de un proyecto (es decir tendría summary y descripción detallada, etc). Crear una lista (sugerencias [EMAIL PROTECTED] o [EMAIL PROTECTED]) que solo esté destinada a anunciar temas de SwL (entre ellos creación de prjs ;) y nos quitaremos muchos OT de arriba en linux-l. Semejante lista se parecería (referencia) a la lista de anuncios de python.org. Configurar a Trac para que notifique la creación de tickets para esta lista... y voilá... ya está notificaremos prjs por doquier ;) (esto es relativamente fácil y no hay que desarrollar mucho porque la mayor parte se basa en la infra estructura del Trac + la ayuda del plugin de XML-RPC para Trac... síiiiii esto si que no lo tiene ninguno y es muy útil para integrar el Trac con IDEs como Eclipse y otros a través de protocolos abiertos, ya que expone toda la funcionalidad de Trac - créanme toda- a través de XML-RPC, créanme. Es decir uno puede tener una página del wiki de Trac en una pestaña del Eclipse p.ej. modificarla, y se actualiza todo en el serve remoto via XML-RPC... y creo que recientemente también JSON-RPC... Esto lo probé yo mismo con Python i.e. xmlrpclib.ServerProxy) - Screenshots ... no lo considero un servicio crítico. - Tracker con search ... por favor esto está de más ... - Mailing lists para cada prj... esto debería estar aparte... la infraestructura en el sitio está creada, y también se podría recurrir al caso de no dar soporte para listas, aunque esto sea muy cómodo para prjs distrib - Forums ... servicio aparte en com.swl.cu - Code ... lo que ellos tienen es SVN + CVS ... y nosotros podríamos hasta tener más e integrar más con el Trac ... cómo ya les dije - Download + File Releases ... hay un plugin que es para esto, que sí da estadísticas de descarga por meses, etc... permite crear paquetes y releases á la SF.net (no sé si están familiarizados con el servicio, incluso IMO está hasta superior que SF.net debido a que permite hacer varias cosas al mismo tiempo... donde más tiempo yo pierdo en SF.net es haciendo los releases, la interfaz no te permite avanzar y no está muy bien diseñada con respecto a «usabilidad» y esto no me gusta definitivamente) y protege opcionalmente contra el uso de robots por mediación de PyCaptcha... Esto lo uso yo actualmente por acá (i.e. funciona...). - Members... Trac Permissions - Registration... Account Mngr plgin (lo uso, i.e. funciona) - DocManager ... PyDoc plugin (lo uso, i.e. funciona) y es superior que el de SF.net en el sentido que el mismo código queda documentado y esto se reutiliza para el sitio... - Otros servicios que considero cosméticos o postergables al menos para empezar Recruitment, Public Info, Backups, Hosted apps, Shell (SSH), DB... El de news podría manejarse con la idea anterior y la lista de anuncios. Trac facilita otros que SF.net no... como por ejemplo browse del repo SVN u otro, InterTrac, y más a través de plugins... > pero es más no > dudaría que esa pagina inicial fue escrita por alguien de ese hosting, Claro un front-end sencillo a Trac... que también tiene sus inconvenientes y cosas que no me gustan, por cierto... pero es posible hacer cosas mejores. > entonces que queremos yo, moya, servilio y varios otros, pues instalar > algo que sea sencillo, de instalar... Trac es sencillo de instalar pero habría que gastar un tiempo para hacer lo que fui indicando arriba y uno mucho menor para dejar listos los plugins necesarios para que eso camine. Ahora a mi me gustaría tener algo ahí que fuera extensible y configurable a gusto, que algo que fuera monolítico y difícil de adaptar a lo que hace falta ... servicios ... porque la realidad es que a medida que se usan las techs van surgiendo nuevas needs. Poe ejemplo yo tenía la idea de hacer una especie de CheeseShop (repositorio de paquetes de Python) para tenerlo synch con el de python.org y permitir registros desde cu que se synch al de allá, etc... Qué admin de prjs permite eso? Ninguno que yo sepa (y así pasa con muchas ideas que con el tiempo se pueden esclarecer mejor). Esto habría que hacerlo. Pero si se usa un amin prj monolítico que no se puede extender... será más dificil después añadir otros servicios y estaríamos amarrados a desarrollos externos para mejorar la infraestructura... o no? además hablando en plata... hubo hace tiempo un forge en swl.cu que no funcionó... ni siquiera pude crear un prj (y ganas no me faltaron) > que promueva y saque a la luz proyectos, vaya > que cuando llegues a: > http://comunidad.softwarelibre.cu/forja/ > > te reciba algo, que muestre información sobre los proyectos que se > hospedan, Esto ya... > que hay nuevo, Esto se podría hacer partiendo de la idea anterior con la lista de anuncios > que se ha modificado hace poco tiempo, Esto también es posible... un InterTrac al recent changes del proyecto de creacion de prjs (meta-prj) > que > está más activo, Esto es más difícil ya... > lease sourceforge.net. > Ya comenté acerca de esto... > Eso es lo que estoy casi seguro quieren decir Moya y Servilio con lo > de multiproyecto, Ya comprendo que era una cuestión de synch... > no si trac es capaz o no de en un solo hosting tener > varios proyectos, por lo que dices InterTrac tampoco es lo que > queremos. > InterTrac es para referenciar páginas de otros Trac en tus páginas de tu Trac... No para «multiprj» > Ahora nos explicamos? o todavía me vas a decir que trac si es > multiproyecto Hubieran empezado por ahí... > y que simplemente de este lado no tenemos idea de lo que > es un software para gestión de proyectos o no sabemos ni lo que > queremos. No, no... capto ahora que era cuestión de vocabulario. -- Regards, Olemis. _______________________________________________ Cancelar suscripción https://listas.softwarelibre.cu/mailman/listinfo/linux-l Buscar en el archivo http://listas.softwarelibre.cu/buscar/linux-l
