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

Update dev-guidelines.html

Browse Source 
remove Trac references, zzz forum, "we/ our" references , add "release manager."
This commit is contained in:
Sadie Mascis
2023-04-28 15:11:44 -04:00
committed by GitHub
parent 09e20cb0ba
commit 9ad45220b8
1 changed files with 12 additions and 13 deletions
Download Patch File Download Diff File Expand all files Collapse all files

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

@ -20,7 +20,7 @@ check with the appropriate developer for guidance.
<ul>
<li>{% trans -%}
Please don't just "write code". If you can, participate in other development activities, including:
development discussions and support on IRC, zzz.i2p, and i2pforum.i2p; testing;
development discussions and support on IRC, i2pforum.i2p; testing;
bug reporting and responses; documentation; code reviews; etc.
{%- endtrans %}</li>
<li>{% trans -%}
@ -34,9 +34,9 @@ the checkin deadline for a release.
<h3>{{ _('Release Cycle') }}</h3>
<p>
Our normal release cycle is 6-12 weeks.
The normal release cycle is 6-12 weeks.
Following are the approximate deadlines within a typical 8-week cycle.
Actual deadlines for each release are set by the lead developer after consultation with the full team.
Actual deadlines for each release are set by the release manager after consultation with the full team.
</p>
<ul>
@ -151,7 +151,7 @@ Be familiar with common Java pitfalls that are caught by findbugs.
Run 'ant findbugs' to learn more.
{%- endtrans %}</li>
<li>
We require Java 8 to build and run I2P as of release 0.9.47.
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.
@ -258,7 +258,7 @@ 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 lead developer.
and obtain approval from the release manager.
{%- endtrans %}</li>
<li>{% trans -%}
If you do obtain approval to add external code or jars,
@ -278,19 +278,18 @@ Include the license and source information in the checkin comment.
<h3>{{ _('Bugs') }}</h3>
<ul>
<li>{% trans trac=i2pconv('trac.i2p2.i2p') -%}
Managing Trac tickets is everybody's job, please help.
Monitor {{ trac }} for tickets you have been assigned or can help with.
Assign, categorize, comment on, fix, or close tickets if you can.
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.
{%- endtrans %}</li>
<li>{% trans -%}
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.
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.
{%- endtrans %}</li>
<li>{% trans -%}
Close a ticket when you think you've fixed it.
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".