From: Luke Kenneth Casson Leighton Date: Fri, 22 Sep 2023 09:30:41 +0000 (+0100) Subject: moved bug process page to HDL_workflow X-Git-Url: https://git.libre-soc.org/?a=commitdiff_plain;h=f924c90239a1144462a725a9095795dd1f470ebb;p=libreriscv.git moved bug process page to HDL_workflow also needed to be done: link it *into* HDL_workflow --- diff --git a/HDL_workflow/libresoc_bug_process.mdwn b/HDL_workflow/libresoc_bug_process.mdwn new file mode 100644 index 000000000..7932d6987 --- /dev/null +++ b/HDL_workflow/libresoc_bug_process.mdwn @@ -0,0 +1,102 @@ +# LibreSOC Bug Process + +* [Bug #1126](https://bugs.libre-soc.org/show_bug.cgi?id=1126) + +* HDL workflow guide page: [[HDL_workflow]] + +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 +for the tasks completed. + +# Why raise issues + +* [Bug #1126](https://bugs.libre-soc.org/show_bug.cgi?id=1126) + +If you have discovered a problem in Libre-SOC (software, hardware, etc.), +please raise a bug report! +Bug reports allow tracking of issues, both to make the developers lives easier, +as well as for tracking completed grant-funded work. + +It is **extremely** important to link the new bug to previous ones. As Luke +mentioned on [this bug](https://bugs.libre-soc.org/show_bug.cgi?id=1139#c3), +"it is a mandatory project requirement that the graph from any bug +contain all other bugs (one "Group")". + +The primary reason for this is to ensure bugs don't get buried and lost, +and will aid those tackling similar problems at a later time. + +Also, for project management and financing purposes, it helps developers +to keep an up-to-date list of their tasks. + +##How to raise issues + +1. Create a bug report. +2. Add in any links from the mailing list or IRC logs to the bug report for back tracking + (this is mandatory). Also fill in the URL field if there is a relevant wiki page. +3. CC in relevant team members +4. make absolutely sure to fill in "blocks", "depends on" or "see also" so that the + bug is not isolated (otherwise bugs are too hard to find if isolated from everything else) +5. Ping on IRC to say a bug has been created +6. Unless you know exactly which milestone to use, leave blank initially. This +also applies when editing milestone, budget parent/child, toml fields. See +section [[HDL_workflow#Task management guidelines]] further down. +7. After setting the milestone, it is **absolutely required** to run +[budget-sync](https://git.libre-soc.org/?p=utils.git;a=blob;f=README.txt;hb=HEAD), +as it will point out any discrepancies. The budget allocations will be used for +accounting purposes and **MUST** be correct. *Note you can only get paid for +stuff done **after the nlnet grant is approved** (before the MOU is signed)* + +If a developer ever needs to check which bugs are assigned to them, go to the +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" + +# Adding sub-tasks to tasks under existing milestone + +* notify Michiel and the relevant NNNN-NN@nlnet.nl team of + advance notice of intent to add new sub-tasks, cc'ing bob + goudriaan + - confirm with them that this is NOT a change in the AGREED + MILESTONE BUDGETs, because it is just sub-task allocation. + - confirm that they are happy to add the sub-tasks to the MoU + (this needs approval of bob goudriaan) +* *re-generate* the JSON file +* make a DIFF against the *PREVIOUS* JSON file +* create a MANUAL report/summary of "changes" that + NLnet may easily action + - "add the following task X to parent Y of amount W", + - and if any: "change parent Z available amount to V as a WRAPUP") + (this latter is because occasionally there are subtasks **not** + totalling the full parent amount, usually because a summary + report is needed. Michiel and I privately agreed to call + this "wrapup") +* obtain a confirmation that this has been actioned +* **double-check** that the RFP database correctly matches the new + bugzilla status. + +PLEASE NOTE: YOU CANNOT ACTION THE ABOVE UNDER THE FOLLOWING CIRCUMSTANCES + +1. to make a change to the actual budgetary amounts of the + Grant Milestones, without written authorization from Bob + and Michiel. a DIFFERENT PROCEDURE is needed. + this is because NLnet had to go through a 3rd party Verification + Process with the European Union: changing the amounts without + consent is therefore tantamount to fraud. + +2. if there has been an RFP already submitted under a given Milestone, + it becomes NO LONGER POSSIBLE to change the JSON file in NLnet's + system because it is too complex. + + there is one Grant in this complex situation: bug #690, the crypto + grant. it is made much more complex because it *pre-dates* NLnet's + current RFP system, where RFPs were submitted by EMAIL and there + are manual records not fully integrated into the database. + +also note: as the addition of sub-tasks *requires a change to the MOU* +it should NOT be taken lightly, i.e. should not be arbitrarily done +one by one, but only in "batches". + +considerable care therefore has to be taken to ensure that NLnet are +not overloaded, nor that the EU Auditor is given grounds to become +"suspicious" because of a dozen or more alterations to the MOU. +and write your nickname (i.e. andrey etc.). \ No newline at end of file diff --git a/libresoc_bug_process.mdwn b/libresoc_bug_process.mdwn deleted file mode 100644 index 7932d6987..000000000 --- a/libresoc_bug_process.mdwn +++ /dev/null @@ -1,102 +0,0 @@ -# LibreSOC Bug Process - -* [Bug #1126](https://bugs.libre-soc.org/show_bug.cgi?id=1126) - -* HDL workflow guide page: [[HDL_workflow]] - -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 -for the tasks completed. - -# Why raise issues - -* [Bug #1126](https://bugs.libre-soc.org/show_bug.cgi?id=1126) - -If you have discovered a problem in Libre-SOC (software, hardware, etc.), -please raise a bug report! -Bug reports allow tracking of issues, both to make the developers lives easier, -as well as for tracking completed grant-funded work. - -It is **extremely** important to link the new bug to previous ones. As Luke -mentioned on [this bug](https://bugs.libre-soc.org/show_bug.cgi?id=1139#c3), -"it is a mandatory project requirement that the graph from any bug -contain all other bugs (one "Group")". - -The primary reason for this is to ensure bugs don't get buried and lost, -and will aid those tackling similar problems at a later time. - -Also, for project management and financing purposes, it helps developers -to keep an up-to-date list of their tasks. - -##How to raise issues - -1. Create a bug report. -2. Add in any links from the mailing list or IRC logs to the bug report for back tracking - (this is mandatory). Also fill in the URL field if there is a relevant wiki page. -3. CC in relevant team members -4. make absolutely sure to fill in "blocks", "depends on" or "see also" so that the - bug is not isolated (otherwise bugs are too hard to find if isolated from everything else) -5. Ping on IRC to say a bug has been created -6. Unless you know exactly which milestone to use, leave blank initially. This -also applies when editing milestone, budget parent/child, toml fields. See -section [[HDL_workflow#Task management guidelines]] further down. -7. After setting the milestone, it is **absolutely required** to run -[budget-sync](https://git.libre-soc.org/?p=utils.git;a=blob;f=README.txt;hb=HEAD), -as it will point out any discrepancies. The budget allocations will be used for -accounting purposes and **MUST** be correct. *Note you can only get paid for -stuff done **after the nlnet grant is approved** (before the MOU is signed)* - -If a developer ever needs to check which bugs are assigned to them, go to the -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" - -# Adding sub-tasks to tasks under existing milestone - -* notify Michiel and the relevant NNNN-NN@nlnet.nl team of - advance notice of intent to add new sub-tasks, cc'ing bob - goudriaan - - confirm with them that this is NOT a change in the AGREED - MILESTONE BUDGETs, because it is just sub-task allocation. - - confirm that they are happy to add the sub-tasks to the MoU - (this needs approval of bob goudriaan) -* *re-generate* the JSON file -* make a DIFF against the *PREVIOUS* JSON file -* create a MANUAL report/summary of "changes" that - NLnet may easily action - - "add the following task X to parent Y of amount W", - - and if any: "change parent Z available amount to V as a WRAPUP") - (this latter is because occasionally there are subtasks **not** - totalling the full parent amount, usually because a summary - report is needed. Michiel and I privately agreed to call - this "wrapup") -* obtain a confirmation that this has been actioned -* **double-check** that the RFP database correctly matches the new - bugzilla status. - -PLEASE NOTE: YOU CANNOT ACTION THE ABOVE UNDER THE FOLLOWING CIRCUMSTANCES - -1. to make a change to the actual budgetary amounts of the - Grant Milestones, without written authorization from Bob - and Michiel. a DIFFERENT PROCEDURE is needed. - this is because NLnet had to go through a 3rd party Verification - Process with the European Union: changing the amounts without - consent is therefore tantamount to fraud. - -2. if there has been an RFP already submitted under a given Milestone, - it becomes NO LONGER POSSIBLE to change the JSON file in NLnet's - system because it is too complex. - - there is one Grant in this complex situation: bug #690, the crypto - grant. it is made much more complex because it *pre-dates* NLnet's - current RFP system, where RFPs were submitted by EMAIL and there - are manual records not fully integrated into the database. - -also note: as the addition of sub-tasks *requires a change to the MOU* -it should NOT be taken lightly, i.e. should not be arbitrarily done -one by one, but only in "batches". - -considerable care therefore has to be taken to ensure that NLnet are -not overloaded, nor that the EU Auditor is given grounds to become -"suspicious" because of a dozen or more alterations to the MOU. -and write your nickname (i.e. andrey etc.). \ No newline at end of file