# 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.).