Dernière mise à jour de la page en January 2017.

Veuillez lire le guide pour nouveaux développeurs d''abord.

Directives de base et style de programmation

La plupart des choses suivantes devraient être de bon sens pour quelqu'un qui a travaillé sur du code source libre ou dans une environnement commercial de programmation. Les choses suivantes s''appliquent surtout à la branche de développement principale i2p.i2p. Les directives pour d'autres branches, plug-ins et applications externes peuvent être considérablement différentes; vérifiez avec le développeur approprié pour des conseils.

Communauté

  • S''il vous plaît n''écrivez pas "juste du code". Si vous pouvez, participer à d'autres activités de développement, incluant : discussions de développement et assistance sur IRC, zzz.i2p et forum i2p; faire des tests; rapports de bugs et réponses; documentation; examens de code; etc.
  • Les dévs actif devrait être disponible périodiquement sur IRC #i2p-dev. Soyez au courant du cycle de sortie actuel. Adhérez pour relâcher - release - des jalons - milestones - tel que gel de caractéristiques, gel d'étiquette et le délai limite pour une sortie.

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

  • Avoir une compréhension de base des systèmes distribués de contrôle de source, même si vous n'avez pas utilisé Monotone auparavant. Demandez de l''aide si vous en avez besoin. Une fois poussé, les checkins sont pour toujours, il n'y a pas d''annulation. Veuillez être prudent. Si vous n''avez pas utilisé Monotone auparavant, commencez par des pas de bébé. Vérifiez dans quelques petites changements et voyez comment cela marche.
  • Testez vos changements avant de les envoyer. Si vous préférez le modèle de développement envoyer-avant-de-tester, utilisez votre propre branche de développement (par exemple i2p.i2p.yourname.test) et une fois que cela marche bien propagez en retour vers i2p.i2p. Ne cassez pas la build. Ne causez pas de régressions. Dans le cas où vous le feriez (cela arrive), veuillez ne pas disparaitre pendant une longue période après avoir poussé vos changements.
  • Si votre changement n'est pas insignifiant, ou que vous voulez que les gens le testent et avez besoin de bons rapports de test pour savoir si votre changement a été testé ou pas, ajoutez un commentaire de checkin dans history.txt et incrémentez la révision de build dans RouterVersion.java.
  • Assurez que vous avez le dernier fichier monotonerc dans _MTN. N'envoyez pas par dessus des révisions non éprouvées.
  • 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.
  • N'envoyez pas de changements majeurs dans la branche principale i2p.i2p tardivement dans le cycle de sortie. Si un projet va vous prendre davantage qu'un couple de jours, créez votre propre branche dans monotone et faites le développement là afin de ne pas bloquer pas les sorties (releases).

Style de programmation

  • Le style de code partout dans la plupart du code est de 4 espaces pour l'indentation. N'utilisez pas de tabulations. Ne re-formatez pas le code. Si votre IDE ou éditeur veulent tout re-formater, prenez-en le contrôle. Oui, nous savons que 4 espaces est une douleur, mais peut-être que vous pouvez configurer votre éditeur convenablement. En quelques endroits, le style de code est différent. Utilisez le bon sens. Imitez le style dans le fichier que vous modifiez.
  • 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.
  • Les classes dans core/ (i2p.jar) et les portions d''i2ptunnel font partie de notre API officielle. Il y a plusieurs plug-ins out-of-tree et d'autres applications qui comptent sur cette API. Soyez prudent de ne pas faire quelconque changement qui casserait cette compatibilité. N''ajoutez pas de méthodes à l''API à moins qu''elles ne soient d''utilité générale. Les Javadocs pour les méthodes d''API devraient être claires et complètes. Si vous ajoutez ou changez l''API, mettez aussi à jour la documentation sur le site Web (branche i2p.www).
  • Étiquetez des chaînes pour traduction quand c'est nécessaire. Ne changez pas de chaînes étiquetées existantes à moins que ce soit vraiment nécessaire, car cela cassera les traductions existantes. N'ajoutez pas ni ne changez les chaînes étiquetées après le "gel d'étiquette" dans le cycle de sortie afin que les traducteurs aient une chance de mettre à jour avant la sortie.
  • Utilisez de classes génériques et concourantes lorsque c'est possible. I2P est une application fortement multi-threaded.
  • 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.
  • Convertissez explicitement entre types primitifs et classes; ne comptez pas sur l'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.

Licences

  • Vérifiez seulement le code que vous avez écrit vous-même. Avant de vérifier n''importe quel code ou bibliothèque issu d''autres sources, justifiez pourquoi c'est nécessaire, vérifiez que la licence est compatible, et obtenez l''approbation du développeur principal.
  • 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
  • Pour n''importe quelles image enregistrée depuis des sources externes c''est votre responsabilité de d''abord vérifier que la licence est compatible. Incluez la licence et sourcez l''information dans le commentaire de checkin.

Bugs

  • Gérer les tickets Trac est le travail de tout le monde, veuillez aider. Surveillez dans trac.i2p2.de les tickets auxquels vous avez été assigné ou auxquels pouvez aider. Assignez, catégorisez, commentez, réparez, ou fermez des tickets si vous le pouvez.
  • 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.
  • Fermez un ticket quand vous pensez que vous l'avez réparé. Nous n'avons pas de département de test pour vérifier et fermer des tickets. Si vous n'êtes pas sûr vous l'avez réparé, fermez le et ajouter une note disant "Je pense que je l'ai réparé, veuillez tester et réouvrir si c'est toujours cassé". Ajoutez un commentaire avec le numéro de build dev ou la révision et mettez le jalon à la prochaine sortie.