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

• Please don't just "write code". If you can, participate in other development activities, including: development discussions and support on IRC, i2pforum.i2p; testing; bug reporting and responses; documentation; code reviews; 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

The normal release cycle is 10-16 weeks, four releases a year. Following are the approximate deadlines within a typical 13-week cycle. Actual deadlines for each release are set by the release manager after consultation with the full team.

• 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.
• 10-14 days before release: String freeze. No more changes to translated ("tagged") strings. Push strings to Transifex, announce translation deadline on Transifex.
• 10-14 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.
• 3-4 days before release: Checkin deadline. No checkins after this time without the permission of the release builder.
• Horas antes del lanzamiento: Fecha límite para la revisión del código.

Git

• Tener una comprensión básica de los sistemas de control de código fuente distribuido, incluso si usted no ha utilizado git antes. Pide ayuda si la necesitas. Una vez enviados, los cambios son para siempre, no se pueden deshacer. Ten cuidado. Si no has usado git antes, empieza con pasos de bebé. Introduce algunos pequeños cambios y mira cómo va.
• Test your changes before checking them in. If you prefer the checkin-before-test development model, use your own development branch in your own account, and create an MR once the work is done. Do not break the build. Do not cause regressions. In case you do (it happens), please do not vanish for a long period after you push your change.
• 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.
• Do not check in major changes into the main i2p.i2p branch late in the release cycle. If a project will take you more than a couple days, create your own branch in git, in your own account, and do the development there so you do not block releases.
• For big changes (generally speaking, more than 100 lines, or touching more than three files), check it into a new branch on your own gitlab account, create an MR, and assign a reviewer. Assign the MR to yourself. Merge the MR yourself once the reviewer approves it.
• Do not create WIP branches in the main i2p-hackers account (except for i2p.www). WIP belongs in your own account. When the work is done, create an MR. The only branches in the main account should be for true forks, like a point release.
• Do development in a transparent fashion and with the community in mind. Checkin often. Checkin or merge into the main branch as frequently as possible, given the guidelines above. If you are working on some big project in your own branch/account, let people know so they may follow along and review/test/comment.

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).
• Etiquete las cadenas para su traducción cuando proceda, lo que es válido para todas las cadenas de la interfaz de usuario. No cambie las cadenas etiquetadas existentes a menos que sea realmente necesario, ya que romperá las traducciones existentes. No añada ni cambie cadenas etiquetadas después de la "congelación de etiquetas" en el ciclo de lanzamiento para que para que los traductores tengan la oportunidad de actualizar antes del lanzamiento.
• 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.
• Java 8 is required to build and run I2P as of release 0.9.47. Do not use Java 7 or 8 classes or methods in embedded subsystems: addressbook, core, i2ptunnel.jar (non-UI), mstreaming, router, routerconsole (news only), streaming. These subsystems are used by Android and embedded applications that require only Java 6. All classes must be available in Android API 14. 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.
• Try-with-resources cannot be used in embedded subsystems as it requires java.lang.AutoCloseable in the runtime, and this is not available until Android API 19 (KitKat 4.4).
• The java.nio.file package cannot be used in embedded subsystems as it is not available until Android API 26 (Oreo 8).
• Other than the above limitations, Java 8 classes, methods, and constructs may be used in the following subsystems only: BOB, desktopgui, i2psnark, i2ptunnel.war (UI), jetty-i2p.jar, jsonrpc, routerconsole (except news), SAM, susidns, susimail, systray.
• Plugin authors may require any minimum Java version via the plugin.config file.
• 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().
• Don't add code to format dates and times. Use DataHelper.formatDate() and formatTime().
• 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

Registro (log)

• For any messages not displayed at the default log level (WARN, INFO, and DEBUG), unless the message is a static string (no concatenation), always use log.shouldWarn(), log.shouldInfo(), or log.shouldDebug() before the log call to avoid unnecessary Object churn.
• Log messages that may be displayed at the default log level (ERROR, CRIT, and logAlways()) should be brief, clear, and understandable to a non-technical user. This includes exception reason text that may also be displayed. Consider translating if the error is likely to happen (for example, on form submission errors). Otherwise, translation is not necessary, but it may be helpful to search for and reuse a string that is already tagged for translation elsewhere.
• Log messages not displayed at the default log level (WARN, INFO, and DEBUG) are intended for developer use, and do not have the above requirements. However, WARN messages are available in the Android log tab, and may be of assistance to users debugging issues, so use some care with WARN messages as well.
• INFO and DEBUG log messages should be used sparingly, especially in hot code paths. While useful during development, consider removing them or commenting them out after testing is complete.
• Do not log to stdout or stderr (wrapper log).

Licencias

• Only check in code that you wrote yourself. Before checking in any code or library jars from other sources, justify why it is necessary, verify the license is compatible, and obtain approval from the release manager.
• 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

• Managing issues are everybody's job, please help. Monitor for issues you can help with. Comment on, fix, and close issues if you can.
• New developers should start by fixing issues. When you have a fix, attach your patch to the issue and add the keyword 'review-needed'. Do not close the issue 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.
• Close an issue when you think you've fixed it. We don't have a test department to verify and close tickets. If you arent sure you fixed it, close it and add a note saying "I think I fixed it, please test and reopen if it's still broken". Add a comment with the dev build number or revision and set the milestone to the next release.