I2P_Developers/i2p.www
3
0
Fork 5
Code Issues 27 Pull Requests Actions 1 Packages Projects Releases Wiki Activity

dev guidelines update

Browse Source
This commit is contained in:
zzz
2025-03-11 11:00:12 -04:00
parent 499356202b
commit b00c64593a
1 changed files with 26 additions and 13 deletions
Download Patch File Download Diff File Expand all files Collapse all files

39
i2p2www/pages/site/get-involved/guides/dev-guidelines.html
View File

@ -1,6 +1,6 @@
{% extends "global/layout.html" %}
{% block title %}{{ _('Developer Guidelines and Coding Style') }}{% endblock %}
{% block lastupdated %}2022-01{% endblock %}
{% block lastupdated %}2025-03{% endblock %}
{% block content %}
<p>{% trans newdevs=site_url('get-involved/guides/new-developers') -%}
Read the <a href="{{ newdevs }}">new developers guide</a> first.
@ -34,8 +34,8 @@ the checkin deadline for a release.
<h3>{{ _('Release Cycle') }}</h3>
<p>
The normal release cycle is 6-12 weeks.
Following are the approximate deadlines within a typical 8-week cycle.
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.
</p>
@ -87,8 +87,8 @@ Check in some small changes and see how it goes.
<li>{% trans -%}
Test your changes before checking them in.
If you prefer the checkin-before-test development model,
use your own development branch
and propagate back to i2p.i2p once it is working well.
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.
@ -99,17 +99,30 @@ to know whether your change was tested or not, add a checkin comment to history.
and increment the build revision in RouterVersion.java.
{%- endtrans %}</li>
<li>{% trans -%}
Ensure that you 'git pull' 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.
{%- endtrans %}</li>
<li>{% trans -%}
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
and do the development there so you do not block releases.
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.
{%- endtrans %}</li>
<li>
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.
</li>
<li>
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.
</li>
<li>
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.
</li>
</ul>
<h3>{{ _('Coding Style') }}</h3>
<ul>
<li>{% trans -%}
@ -277,7 +290,7 @@ Include the license and source information in the checkin comment.
<h3>{{ _('Bugs') }}</h3>
<ul>
<li>{% trans trac=i2pconv('trac.i2p2.i2p') -%}
<li>{% trans trac=i2pconv('git.idk.i2p') -%}
Managing issues are everybody's job, please help.
Monitor {{ Gitlab }} for issues you can help with.
Comment on, fix, and close issues if you can.