[Buoh-dev] Un poco de politicas

[Carlos Garcia Campos]

El vie, 25-02-2005 a las 21:41 +0100, Esteban Sánchez escribió:
>Buenas, buihstas :P
>
>Tampoco vamos a bombardear la lista cada vez que hagamos un commit, pero
>esta vez voy a decir que he hecho commit donde básicamente he añadido la
>funcionalidad de guardar en un fichero los comics que ha elegido el
>usuario.
>
>Si habeis estado probándolo últimamente, os habreis fijado en que no
>guardaba la lista que elegías, así que era un coñazo tremendo. Kal me
>dijo una cosa muy interesante al respecto y os la transmito al resto, ya
>que como somos newbies seguramente se nos haya ocurrido.
>
>La idea es que la versión de CVS esté siempre en un estado consistente.
>Es decir, si se piensa añadir una funcionalidad, no debe de hacerse
>commit hasta que esa funcionalidad esté implementada y lista para
>probar. En ese punto cualquiera le podrá meter mano bien a fondo. Esto
>evita que se creen problemas con la versión de CVS, y así conseguimos
>tener siempre una versión usable en el servidor.
>
>Sin embargo, esto puede dar a entender que cada uno debe de hacerse una
>funcionalidad y hasta que no la tenga lista no puede ser ayudado por los
>demás. Evidentemente, no tiene lógica, así que la manera de trabajar es
>con parches sobre la versión de CVS que se cuelgan en la forja (sección
>de Patches) y el que quiera pueda aplicar sobre su versión de
>desarrollo.

Tampoco hace falta ser demasiado estricto, vamos que ni una cosa ni
otra. La idea es que si vamos a implementar una funcionalidad si falta
algun que es muy importante pues, o bien se manda un mail a la lista
explicando que se ha hecho commit y el estado en el que está el CVS o se
implementa al menos lo básico aunque falten detallitos. El CVS está para
trabajar sobre el, y es posible por ejemplo añadir un menu y que no
tenga codigo, porque tienes pensarlo darselo después. No hay problema
siempre y cuando se avise, pero no en el changelog, sino en la lista de
correo. Otra forma es que si estás preparando algo tocho y no quieres
hacer ci porque todavía no es consistente o estable, pero quieres que
otros lo puedan probar, puedes hacer un parche, que cualquiera puede
aplicar y probar si quiere. En el caso mas extremo, si la funcionalidad
es muy my tocha o incluso en los casos en los que se va a reescribir
gran parte del codigo, o cambios en la arquitectura que afectan todas
las partes de la aplicación se suele hacer un branch del CVS. Consiste
en tener 2 o mas ramas. Una es estable y consistente y la otra es la
rama de desarrollo sobre la que estás trabajando. Si haces un branch
avisas y dices para que es la nueva rama. 

>Kal: podrías explicar cómo hacer un parche? Creo que es con el comando
>"cvs diff", verdad? Sé apl

cvs diff -u > archivo.diff

>Para poder empezar a usar la forja es importante que os deis de alta
>https://secure-www.novell.com/selfreg/jsp/createAccount.jsp?target=http%
>3A//forge.novell.com/modules/news/index.php
>
>
>El sistema de alta no parece funcionar muy bien, intentadlo desde varios
>sitios porque a mi en mi casa no me funcionaba, pero en la universidad
>sí. Cuando lo hayais hecho mandadme un email con vuestro login para que
>os ponga como desarrolladores. 
>
>Un saludo gente :)

Salu2
-- 
=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
 Carlos Garcia Campos a.k.a. KaL
   elkalmail at yahoo.es
   carlosgc at gnome.org
   http://carlosgc.linups.org
=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=             
PGP key: http://pgp.mit.edu:11371/pks/lookup?op=get&search=0x523E6462
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: This is a digitally signed message part
Url : http://forge.novell.com/pipermail/buoh-dev/attachments/20050226/a7c211f0/attachment.pgp