[Jde] Permisos de acceso al Trac de JDE...

[JoseMaria]

Hola,

> > Por ejemplo, el fujo ideal para este caso sería.
> > 1. Pones el ticket en el trac. El ticket debe ser meramente descriptivo.
> > 2. Mandas un correo a la lista comentando el ticket, y adjuntando el
> > Makefile o los ficheros que sean necesarios. Es en la lista dónde se
> > debe dar la conversación sobre un ticket.
> > 3. Alguna de las personas que tiene permisos para hacer commits en el
> > subversion se asigna el ticket, hace unas mínimas pruebas, sube los
> > cambios al repositorio y te vuelve a asignar a ti el ticket.
> > 4. Compruebas también con unas mínimas pruebas que funciona todo bien y
> > cierras el ticket.


El procedimiento correcto es este que menciona Roberto. Tras unos
cuantos años trabajando con jde ahora queremos dar un salto de calidad
con el código y estamos empezando con los usos y costumbres de los
buenos proyectos de software libre. Es natural que nos surjan dudas como
la tuya, Antonio.

En la comunidad de jde, como en otros proyectos grandes, hay usuarios y
desarrolladores. Como no somos muchos, de momento hemos unificado a
ambos en una única lista (jde en gsyc.es). Si seguimos creciendo llegará un
momento en que tenga sentido manejar dos listas separadas porque las
preguntas, las cosas de las que hablan unos y otros, suelen ser
distintas. 

Los desarrolladores  son el verdadero motor del proyecto, y
desarrolladores somos todos los que mejoramos el código, sin
exclusiones. Y la manera 'correcta' de aportar esas mejoras es via
parches [1]. Dentro de ellos hay varios que además coordinan todos los
aportes al software. Su misión es mantener la coherencia de todo el
proyecto y necesariamente su número es muy reducido. Para que os hagais
una idea, todo el desarrollo del simulador Gazebo lo coordina un tal
Nate Koening. Y para todo el proyecto Player/Stage, sólo 2 personas
tienen permisos de escritura en el svn oficial, y hay decenas de
desarrolladores por todo el mundo.

Los coordinadores conocen todos los detalles de la plataforma
completamente y mantienen una comunicación fluida, casi diaria (vamos
que es un marrón :-)). Es tarea suya revisar todos los aportes que dan
los desarrolladores. Algunos los incorporarán, otros los rechazarán y
otros los mandarán de vuelta a la espera de algunas correcciones antes
de subirlos a la distribución oficial. Es una medida de aumentar la
calidad del software.

> > En el subversion de JDE únicamente tienen permisos para realizar commits
> > 3 personas. Échale un ojo al siguiente enlace, donde comenta como
> > notificar bugs y nuevas características (hemos dejado de usar el trac
> > para adjuntar los parches).
> > http://jde.gsyc.es/index.php/FAQ#How_do_I_send_a_patch_or_new_feature.3F
> 
> Yo no tengo ningún inconveniente en enviar un correo cuando encuentre un
> bug, pero seguramente en breve os estaré incomodando porque enviaré
> parches cada dos por tres en el momento en que encuentre cosas que no
> funcionen. 


No te preocupes, no incomoda!!. Al revés, cuantos más parches y
modificaciones que mandemos a la lista de correo, más calidad y mejoras
tendrá nuestro software.  Así que cuanto más des la lata con parches a
la lista, mejor :-) 

> > El driver 'networkserver' se movió a la carpeta de servicios, ya que no
> > genera ningún esquema y por tanto lo tratamos como un componente de
> > servicio (seguramente Jose María pueda comentar mejor las razones sobre
> > esto). Así pues, el driver lo tienes aquí:
> > https://svn.jde.gsyc.es/jde/jdec/trunk/services/

"Networkserver" sigue estando en la distribución, pero ahora en el
directorio servicios. Su funcionalidad es vital para tener sensores
remotos! Jde es una arquitectura basada en componentes, pero no todos
los componentes son iguales, y las distinciones se van haciendo más
claras a medida que acumulamos más horas de vuelo con jde. No es una
distinción objetiva universal, pero hoy parece razonable diferenciar
entre esquemas, drivers y componentes de servicio:

- El esquema es la unidad básica. Su ejecución se puede detener y
relanzar a voluntad. Tienen un API clásico (guiresume, guisuspend,
startup, resume, suspend...) y el específico con los datos de cada cual.

- Los drivers típicamente se conectan a algún dispositivo (real o
simulado) para obtener lecturas sensoriales u ordenar comandos a los
actuadores. Normalmente generan varios esquemas virtuales, que también
se pueden detener y relanzar a voluntad. Por ejemplo el driver player
genera los esquemas virtuales laser, motors, encoders, etc., el driver
firewire genera los esquemas virtuales colorA, colorB, etc.. dependiendo
de su configuración.

- Los componentes de servicio proporcionan alguna funcionalidad, pero no
en forma de esquemas. Por ejemplo, los componentes graphics_xforms y
graphics_gtk permiten a los esquemas programar sus GUIs. El componente
webservice arranca un servidor que habla SOAP con otras aplicaciones
incluso remotas. El propio networkserver arranca un servidor tcp para
conexión de otros programas.

La nueva distribución de directorios en el codigo fuente trata de
reflejar estas distinciones. 

Seguimos hablando. Ánimo!!

JoseMaria
[1]
http://jde.gsyc.es/index.php/FAQ#How_do_I_send_a_patch_or_new_feature.3F
-- 
http://gsyc.es/jmplaza 
Universidad Rey Juan Carlos