openerp-l10n-ar-localization team mailing list archive

[Cristian Sebastian Rocha <cristian.rocha@xxxxxxxxxxx>]

Ignacio,

el tema de la autoría es muy delicado y me gustaría ponerlo desde este
punto de vista: Si A pone los cimientos y B construye el edificio
sobre ellos, la autoría del edificio es de A y B. Si B hubiera querido
ser el único autor del edificio debería haber hecho el edificio en
otra parte. Estoy consultando a Niv Sardi
(http://qa.debian.org/developer.php?login=xaiki+deb@xxxxxxxxxxxxx) que
es desarrollador de Debian y vive aquí en BsAs para que me de un punto
de vista más standard de la comunidad OS.

Sobre el Bug, el workflow que planteas es correcto. Yo agregaría un
punto más que es: no se reconoce un bug hasta que exista un test que
lo provoque. Esto es un problema porque muchas veces los bug son
difíciles de identificar, pero si va a permitir tener un desarrollo de
calidad.

Con respecto a los test, te puedo asegurar que es el método Oficial de
OpenERP para realizar test. No solo me base en su documentación, sino
que también revisé todo el código de OpenERP y sus módulos para
confirmalo.

Abrazo,
Cristian.

2012/10/5 Lopez Ignacio <lopezignacio@xxxxxxxxx>:
> Gracias Cristian por responder.
>
> Bueno, yo no estoy de acuerdo que ponerce como autor de un modulo vacío que
> sirva para "conquistar el mundo" (pero que no contenga nada) y que venga
> otro y que efectivamente lo conquiste y ser parte del credito o "iniciador"
> de la conquista. Para mi esto desalienta al que realmente quiere
> "conquistarlo" ya que tiene que compartir el crédito del trabajo efectivo.
> Distinto sería mejorar "la conquista del mundo" o agregarle "la conquista de
> la luna".... pero somos solo dos charlando y oponiendo ideas. Éste, es un
> buen tema para consensuar en la reunion de hoy y definirlo.
>
> Lo del Bug, si es cierto. Incluso también note algún comportamiento extraño
> con las direcciones que tienen piso y oficina por ejemplo. Estaba haciendo
> las modificaciones para cuando apareciera el Bug reportado subir el fix
> (como ejercicio del repositorio). Siempre al encontrar un bug, primero hay
> que reportarlo, mas tarde alguien se designa o se pone como responsable de
> la reparación. Te salteaste este paso y obviamente eso no es nada serio,
> estuvo bueno que pasara así para los próximos vamos mejorando. Voy a
> levantar tus modificaciones y probarlas y ver si puedo acomodar lo que ya
> estaba haciendo.
>
> Todo esto si lo es que lo consensuamos que se haga así, porque en verdad es
> solo mi pensamiento de como debiera funcionar la mecánica del repositorio
> comunal. En verdad estamos iniciándolo y todas estas cosas son todas
> primeras veces.
>
> También el tema de los test lo vamos a charlar hoy a la tarde. Juan
> Cristobal va a comentar cual era la manera para llevar los test según lo que
> ya esta pensado para los módulos (que desconozco) y puede o no ser lo mismo
> que hiciste. Ojala que sea así no tocamos eso.
>
> Muchas gracias por ocuparte y estamos colaborando.
>
>
> Buena Vida!
>
> Ignacio López
> www.dinamotion.com.ar
>
>
> El 04/10/12 17:25, Cristian Sebastian Rocha escribió:
>
>> Hola Ignacio,
>>
>> voy a intentar responder a todas la preguntas así comento los cambios
>> que hice en el módulo.
>>
>>> 1) ¿Encabezar un modulo te hace autor?... esto es... en el caso de este
>>> modulo lo que se hizo fue trasladar lo que estaba hecho en el otro repo y
>>> hacer el fork aquí sin modificaciones. Mas tarde lo converti en un modulo
>>> funcional. Yo creo que el traslado del modulo no te hace autor, pero
>>> ¿hiciste modificaciones?... creo que autores, deben ser los que aportan
>>> código al proyecto (Y ahora debo aclarar que este no fue el motivo que
>>> origino este mail aunque esta bueno que surja.).
>>
>> Autor es cualquiera que aporte. Mover de lugar unos archivos para
>> tener algún beneficio, de mi parte lo considero autor. Ahora, no es el
>> autor principal, eso está claro. Por eso es necesario, en todo lo que
>> sea opensource tener un lugar donde dejar una lista. Y si se puede,
>> indicar en que forma aportó en el código. Al principio estaba pensando
>> agrupar a los autores por actividades que tuvieron en el código, pero
>> me embolé y no lo hice.
>>
>>> 2) Crear un modulo vacío de contenido y ponerse como autor, a mi
>>> entender,
>>> no tiene sentido. Esto es, crear el encabezado del modulo y poner la
>>> licencia que no hace a la funcionalidad del modulo en cuestión, es solo
>>> una
>>> mera tarea administrativa por cierto que corresponde y debe hacerse. Eso
>>> no
>>> hace al administrador, un autor.
>>
>> Crear un módulo vacío es haber creado un módulo vacío. Es autor de un
>> módulo vacío. Si el objetivo del módulo era dominar al mundo, pero
>> sigue vacío, el autor es solo autor de un módulo vacío y no de dominar
>> el mundo. Quiero que quede claro que la autoría, aunque pequeña que
>> sea debe ser reconocida. Lo que no se puede reconocer es la NO
>> autoría. Se entiende?
>>
>> En un momento comentaste del campo "update":
>>
>>> Ese campo es para humanos. Tiene la idea de ver cuando fue la ultima toma
>>> de datos.
>>>
>>> La lógica que utilizo es:
>>>
>>> - Desactivo TODOS los bancos Argentinos
>>> - Actualizo y activo los que encuentro iguales (criterio del punto 1 de
>>> este mail)
>>> - Agrego los que no encontré.
>>>
>>> En cuanto a agregarlos como clientes, no me parece correcto. Eso es un
>>> trabajo humano y normalmente los
>>> humanos no les gusta que le metan la mano es su trabajo.
>>> Informaticamente, no sería un problema. También
>>> pienso que solo algún caso querrá esto, a ese, que pida la modificación.
>>> Para la mayoría esto funciona bastante bien.
>>>
>>> Problemas cercanos que veo:
>>>
>>> - La información tomada, es solo de las casas matrices y casas centrales.
>>> No de las sucursales.
>>
>> Me parece bien la lógica y entiendo el campo para humanos, pero me
>> supera. Supongo que hiciste un relevamiento
>> y te apareció que el cliente necesitaba saber cuando fue la última vez
>> que se actualizó el dato del banco.
>> Si es así todo bien, no hay nada que discutir. Por otra parte me gustó
>> la idea de utilizar el CUIT como clave primaria,
>> muy inteligente.
>>
>> Y ahora paso a otro tema....
>>
>> Escribí un test para l10n_ar_bank que ejecuta el wizard y revisa si se
>> realizó la actualización. Es un test muy rudimentario, pero
>> suficientemente bueno para que surgiera el siguiente bug:
>>
>> "El sistema confunde ciudades con provincias. El caso específico viene
>> por el lado de Ushuaia."
>>
>> Ya reparé el bug, realicé el commit en el repositorio, y ahora desde
>> modo de testing no tirá más errores. Habría que probar el Wizard desde
>> la interface web a ver que pasa.
>>
>> También agregué un teste para l10n_ar_base_vat. Simple también, pero
>> no identificó ningún bug, pero eso era de esperar.
>>
>> Eso es todo.
>>
>> Abrazo,
>> Cristian.
>>
>