mention page number of vgbbd
[libreriscv.git] / HDL_workflow / libresoc_bug_process.mdwn
index 76629bf4aba052c097c6ecd1c8243e1c2437323d..1d74e36dc74691a49f181ebec5e058444ad7b283 100644 (file)
@@ -7,6 +7,7 @@
 * [Bug #1126](https://bugs.libre-soc.org/show_bug.cgi?id=1126)
 
 * HDL workflow guide page: [[HDL_workflow]]
+* RfP submission process: [[HDL_workflow/rfp_submission_guide]]
 
 This page describes in detail how to raise new tasks (bugs) and how to approach
 development within the project in order to get appropriate amount of funding
@@ -57,6 +58,29 @@ Libre-SOC bug tracker
 [advanced search page](https://bugs.libre-soc.org/query.cgi?format=advanced),
 and in the "Search by People" section, check "Bug Assignee" and "contains"
 
+## Additional info
+
+### Linking bugs - 'use bug#NNN' format
+
+- When mentioning other bugs in bug description or comment, use the
+"bug #NNN" format, and not "#NNN". For example, writing `bug #1000` in
+in the bugtracker comment section will create a link to
+[bug #1000](https://bugs.libre-soc.org/show_bug.cgi?id=1000).
+Following this syntax ensures the Bugzilla system converts
+every bug reference into a hyperlink which makes things easier to track
+(as you see the interdependencies between various tasks/bugs/milestones etc.).
+
+### Do not attempt to re-use bugs
+
+- As LibreSOC uses the bugtracker system for task management and grant/budget
+allocation, it is critical not to change the purpose of a previously created
+bug. If a duplicate bug has been created, mark as `DUPLICATE` (see the
+procedure section further down on this page on additional types of bugs
+which would not be worked on).
+- All comments cannot be removed (with the exception of having no comments
+other than the initial description, *and* no link/references to other bugs).
+- The bug may also be referenced externally, and thus re-use is not permitted.
+
 # Adding sub-tasks to tasks under existing milestone
 
 * notify Michiel and the relevant NNNN-NN@nlnet.nl team of
@@ -245,6 +269,9 @@ an issue at all, it is to be set to either of the following:
 grant sub-task/s, and budget considered, *then* work can proceed in a separate
 branch. Only after fixes have been confirmed to keep the CI tests passing,
 can they be rebased (to keep commit history) into the master branch.
+  - *Note*: branch names **should not include personal info** such as names.
+    This is because others may require to use or work on the branch, and no
+    single developer owns a branch.
 
 This procedure adds a time delay between the issue discovery and
 start of work. This is important however because it allows for team members