bug 1244: add linked list ddffirst image

[libreriscv.git] / HDL_workflow / libresoc_bug_process.mdwn

diff --git a/HDL_workflow/libresoc_bug_process.mdwn b/HDL_workflow/libresoc_bug_process.mdwn
index 218b36edc08e28d9e93f7ca2acd39f424297a430..1d74e36dc74691a49f181ebec5e058444ad7b283 100644 (file)
--- a/HDL_workflow/libresoc_bug_process.mdwn
+++ b/HDL_workflow/libresoc_bug_process.mdwn
@@ -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
@@ -59,6 +60,8 @@ 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
@@ -67,6 +70,17 @@ 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
@@ -255,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