[Buoh-dev] Un poco de politicas



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 yahoo es
   carlosgc 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


[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]