Esta página fue actualizada por última vez el January 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!!!

Release Cycle

Our normal release cycle is 6-10 weeks. Following are the approximate deadlines within a typical 8-week cycle. Actual deadlines for each release are set by the lead developer.

  • 1-2 days after previous release: Checkins to trunk are allowed.
  • 2-3 weeks after previous release: Deadline to propagate major changes from other branches to trunk.
  • 4-5 weeks before release: Deadline to request new home page links.
  • 3-4 weeks before release: Feature freeze. Deadline for major new features.
  • 2-3 weeks before release: Hold project meeting to review new home page link requests, if any.
  • 7-10 days before release: String freeze. No more changes to translated ("tagged") strings. Push strings to Transifex, announce translation deadline on Transifex.
  • 7-10 days before release: Feature deadline. Bug fixes only after this time. No more features, refactoring or cleanup.
  • 3-4 days before release: Translation deadline. Pull translations from Transifex and check in.
  • 2-3 days before release: Checkin deadline. No checkins after this time without the permission of the release builder.
  • Hours before release: Code review deadline.

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.
  • Ensure that you 'mtn pull' and 'mtn update' to the latest revision before you check in and push. If you inadvertently diverge, merge and push as soon as possible. Don't routinely make others merge for you. Yes, we know that monotone says you should push and then merge, but in our experience, in-workspace merge works just as well as in-database merge, without creating a merge revision.
  • 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.
  • All new public and package-private classes and methods require Javadocs. Add @since release-number. Javadocs for new private methods are desirable.
  • For any Javadocs added, there must not be any doclint errors or warnings. Run 'ant javadoc' with Oracle Java 8 or higher to check. All params must have @param lines, all non-void methods must have @return lines, all exceptions declared thrown must have @throws lines, and no HTML errors.
  • 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.
  • Be familiar with common Java pitfalls that are caught by findbugs. Run 'ant findbugs' to learn more.
  • We require Java 7 to build and run I2P. Do not use Java 8 classes or methods anywhere. Do not use Java 7 or 8 classes or methods in embedded subsystems (core, router, mstreaming, streaming, i2ptunnel), as Android and embedded applications require only Java 6. All classes must be available in Android API 9. Java 7 language features are acceptable in these subsystems if supported by the current version of the Android SDK and they compile to Java 6-compatible code.
  • Convierta explícitamente entre tipos primitivos y clases; no confíe en autoboxing/unboxing.
  • Don't use URL. Use URI.
  • Don't catch Exception. Catch RuntimeException and checked exceptions individually.
  • Don't use String.getBytes() without a UTF-8 charset argument. You may also use DataHelper.getUTF8() or DataHelper.getASCII().
  • Always specify a UTF-8 charset when reading or writing files. The DataHelper utilities may be helpful.
  • Always specify a locale (for example Locale.US) when using String.toLowerCase() or String.toUpperCase(). Do not use String.equalsIgnoreCase(), as a locale cannot be specified.
  • Don't use String.split(). Use DataHelper.split().
  • Ensure that InputStreams and OutputStreams are closed in finally blocks.
  • Use {} for all for and while blocks, even if only one line. If you use {} for either the if, else, or if-else block, use it for all blocks. Put "} else {" on a single line.
  • Specify fields as final wherever possible.
  • Don't store I2PAppContext, RouterContext, Log, or any other references to router or context items in static fields.
  • Don't start threads in constructors. Use I2PAppThread instead of 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.
  • If you do obtain approval to add external code or jars, and binaries are available in any Debian or Ubuntu package, you must implement build and packaging options to use the external package instead. Checklist of files to modify: 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.
  • New developers should start by fixing a bug. Search for bugs with the 'easy' keyword on trac. When you have a fix, attach your patch to the ticket and add the keyword 'review-needed'. Do not close the ticket until it's been successfully reviewed and you've checked your changes in. Once you've done this smoothly for a couple of tickets, you may follow the normal procedure below.
  • 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.