Esta página fue actualizada por última vez el Enero de 2017.

Primero lea la guía para nuevos programadores.

Pautas básicas y estilo del código

La mayor parte de lo siguiente debería ser de sentido común para cualquiera que haya trabajado para proyectos de código libre o en ambientes de desarrollo comerciales. Lo siguiente se aplica sobre todo para el desarrollo de la rama principal i2p.i2p. Las guías para otras ramas, pluguins y aplicaciones externas pueden ser bastante diferentes, pregúntele al desarrollador indicado en tal caso.

Comunidad

  • Por favor no sólo "escriba código". Si puede, participe en otras actividades de desarrollo como: discusiones sobre el desarrollo y soporte en el IRC, zzz.i2p, y el foro de.i2p; reporte y solución de errores; documentación, revisión del código, etc.
  • Los programadores activos deberían estar disponibles periódicamente en el canal #i2p-dev del IRC. Tenga en cuenta el ciclo de liberación de versiones actual. Fix this! not translated all yet!!!

Ciclo de publicación

Nuestro ciclo de publicación normal es de 6-10 semanas. A continuación están las fechas límite aproximadas dentro de un ciclo típico de 8-semanas. Las fechas límite actuales para cada versión están establecidas por el desarrollador jefe.

  • 1-2 días después de la publcación previa: Se permiten inserciones en al ramal troncal (trunk).
  • 2-3 semanas depués de la publicación previa: Fecha límite para propagar cambios principales de otros ramales hacia el troncal (trunk).
  • 4-5 semanas antes de la publicación: Fecha límite para solicitar nuevos enlaces para la página de inicio.
  • 3-4 semanas antes de la publicación: Congelación de características. Fecha límite para nuevas características principales.
  • 2-3 semanas antes de la publicación: Mantenimiento de una reunión del proyecto para revisar las peticiones de nuevos enlaces para la página de inicio, si hay alguna.
  • 7-10 días antes de la publicación: Congelación de cadenas de texto. No se hacen más cambios a las cadenas de texto traducidas ("tagged"). Remisión de cadenas de texto a Transifex, anuncio de la fecha límite para la traducción en Transifex.
  • 7-10 días antes de la publicación: Fecha límite para características. Correción de fallos sólo después de este momento. No más características, refactorizado o limpieza.
  • 3-4 días antes de la publicación: Fecha límite para la traducción. Recogida de traducciones de Transifex e inserción.
  • 2-3 días antes de la publicación: Fecha límite de inserción. No se hacen inserciones después de este momento sin el permiso del constructor de la versión.
  • Horas antes de la publicación: Fecha límite de revisión de código.

Monotone

  • Debe tener conocimientos básicos del funcionamiento de sistemas de control de código, incluso si nunca ha usado monotone antes. Pida ayuda si lo necesita. Una vez subido algo no hay vuelta atrás, no se puede deshacer, por favor tenga cuidado. Si nunca ha usado monotone antes empiece con mucho cuidado. Suba pequeños cambios y observe como funciona.
  • Pruebe los cambios antes de subirlos. Si prefiere el modelo de desarrollo subir-antes-de-probar use su propia rama de desarrollo (por ejemplo i2p.i2p.yourname.test) y envíelo de vuelta a i2p.i2p una vez que funcione correctamente. No rompa la compilación. No cree regresiones. En caso de que lo haga (a veces ocurre), no desaparezca por mucho tiempo antes de subir el cambio.
  • Si su cambio no es trivial, o desea que otra gente lo pruebe y necesita reportes fiables para saber si su cambio ha sido probado o no, añada un comentario de confirmación en history.txt e incremente la versión de compilación en RouterVersion.java.
  • Asegúrese de que tiene la última versión del archivo monotonerc en _MTN. No lo sobrescriba con versiones no confiables.
  • Asegúrese de hacer 'mtn pull' (incorporar) y 'mtn update' (actualizar) a la última revisión antes de registrarse y hacer push (impulsar). Si inadvertidamente hace diverge (bifurcar), haga merge (combinar) y push (impulsar) tan pronto como sea posible. No haga que rutinariamente otros hagan merge por usted. Sí, sabemos que monotone le dice que debería hacer push y luego merge, pero por nuestra experiencia, un merge (combinación) en el espacio de trabajo funciona tan bien como un merge en la base de datos, sin crear una revisión merge.
  • No suba cambios grandes a la rama principal i2p.i2p al final del ciclo de versión. Si un proyecto va a tardar más de varios días, cree su propia rama de monotone y programe allí para no no bloquear la salida de nueva versiones.

Estilo de programación

  • El código de estilo en la mayoría de los casos es de usar la sangría de 4 espacios. No use tabulación. No cambie el formato del código. Si su editor o IDE quiere cambiar el formato configúrelo para que no lo haga. Sí, sabemos que usar 4 espacios es doloroso, pero probablemente pueda configurar su editor apropiadamente. En algunos casos el estilo de programar es diferente, use el sentido común, emule el estilo del archivo que está modificando.
  • Todas las nuevas clases y métodos, públicos y de paquetes-privados, requieren Javadocs. Añada '@since número-de-versión'. Javadocs es deseable para nuevos métodos privados.
  • Para cualquier Javadoc añadido, no debe haber ningún error o advertencia de doclint. Ejecute 'ant javadoc' con Oracle Java 8 o superior para comprobarlo. Todos los parámetros deben tener líneas @param, todos los métodos no-nulos deben tener líneas @return, todas las excepciones declaradas lanzadas deben tener líneas @throws, y no debe haber errores HTML.
  • Las clases del núcleo/ (i2p.jar) y partes de i2ptunnel están incluidas en el API oficial. Hay varios pluguins y otras aplicaciones que dependen de este API. Tenga cuidado de no hacer cambios que rompan la compatibilidad. No añada métodos al API a no ser que sean de utilidad general. Los Javadocs de los métodos del API deben ser claros y completos. Si añade cambios al API, debe también actualizar la documentación en la web (i2p.www branch).
  • Incluya cadenas de texto para la traducción cuando sea apropiado. No cambie las cadenas ya etiquetadas a no ser que sea necesario ya que rompería las traducciones existentes. No añada o cambie las cadenas después del "tag freeze" durante la liberación de la versión, así los programadores tienen la oportunidad de actualizarlo antes de su liberación
  • Siempre que pueda use clases genéricas y concurrentes. I2P es una aplicación multi-hilos.
  • Familiarícese con las trampas comunes de Java que son atrapadas por findbugs. Ejecute 'ant findbugs' para saber más.
  • Requerimos Java 7 para compilar y ejecutar I2P. No use clases o métodos Java 8 en ninguna parte. No use clases o métodos Java 7 u 8 en subsistemas integrados (núcleo, router I2P, mstreaming, streaming, i2ptunnel), ya que Android y las aplicaciones integradas sólo requieren Java 6. Todas las clases deben estar disponibles en Android API 9. Las características del lenguaje Java 7 son aceptables en estos subsistemas si están soportadas por la versión actual del Android SDK y compilan para código compatible-con-Java 6.
  • Convierta explícitamente entre tipos primitivos y clases; no confíe en autoboxing/unboxing.
  • No use URL. Use URI.
  • No atrape Exception. Atrape RuntimeException y excepciones marcadas individualmente.
  • No use String.getBytes() sin un argumento con el juego de caracteres UTF-8. También puede usar DataHelper.getUTF8() o DataHelper.getASCII().
  • Especifique siempre un juego de caracteres UTF-8 al leer o escribir ficheros. Las utilidades DataHelper le pueden ser de ayuda.
  • Especifique siempre una localización (por ejemplo Locale.US) al usar String.toLowerCase() o String.toUpperCase(). No use String.equalsIgnoreCase(), ya que no se puede especificar una localización.
  • No use String.split(). Use DataHelper.split().
  • Asegúrese de que InputStreams y OutputStreams están cerrados en los bloques del final.
  • Use {} para todos los bloques for y while, incluso si sólo tienen una línea. Si usa {} para cualquiera de los bloques if, else, o if-else, úselo para todos los bloques. Ponga "} else {" en una sola línea.
  • Especifique los campos al final siempre que sea posible.
  • No almacene I2PAppContext, RouterContext, Log, o cualquier otra referencia al router I2P o a elementos de contexto específicos, en campos estáticos.
  • No inicie hilos en los constructores. Use I2PAppThread en lugar de Thread

Licencias

  • Sólo suba el código que ha escrito usted. Antes de subir el código o librerías de otras fuentes, verifique que la licencia es compatible, y obtenga permiso del desarrollador.
  • Si obtiene la aprobación para añadir código o jars externos, y los binarios están disponibles en cualquier paquete Debian o Ubuntu, debe implementar opciones de compilación y empaquetado para usar el paquete externo en su lugar. Lista de comprobación de ficheros a modificar: build.properties, build.xml, debian/control, debian/i2p-router.install, debian/i2p-router.links, debian/rules, sub-build.xml
  • Para cualquier imagen subida de fuentes externas, es su responsabilidad verificar primero si la licencia es compatible. Incluya la licencia y la información de la fuente en el comentario de subida.

Bugs

  • Mantener las entradas del Trac es trabajo de todos, por favor denos su ayuda. Observe el trac.i2p2.de por entradas que le hayan sido asignadas o en las que pueda ayudar. Asigne, categorice, comente, arregle, o cierre entradas si puede.
  • Los nuevos desarrolladores deben comenzar por reparar un fallo. Busque fallos con la palabra clave 'easy' (fácil) en trac (monitor de fallos). Cuando tenga una reparación, adjunte su parche a la entrada (ticket) y añada la palabra clave 'review-needed' (precisa revisión). No cierre la entrada hasta que haya sido revisada con éxito y usted haya inscrito sus cambios. Una vez haya realizado esto sin dificultad con un par de entradas, puede seguir el procedimiento normal debajo.
  • Cierre la entrada cuando piense que la ha arreglado. No tenemos un departamento de pruebas para verificar las entradas cerradas. Si no está seguro de haberlo solucionado, ciérrela y añada una nota diciendo "I think I fixed it, please test and reopen if it's still broken". Añada un comentario con el número de compilación o la revisión y establezca el hito para la siguiente versión.