libresoc_bug_process.mdwn

   1 # LibreSOC Bug Process
   2
   3 * [Bug #1126](https://bugs.libre-soc.org/show_bug.cgi?id=1126)
   4
   5 * HDL workflow guide page: [[HDL_workflow]]
   6
   7 This page describes in detail how to raise new tasks (bugs) and how to approach
   8 development within the project in order to get appropriate amount of funding
   9 for the tasks completed.
  10
  11 # Why raise issues
  12
  13 * [Bug #1126](https://bugs.libre-soc.org/show_bug.cgi?id=1126)
  14
  15 If you have discovered a problem in Libre-SOC (software, hardware, etc.),
  16 please raise a bug report!
  17 Bug reports allow tracking of issues, both to make the developers lives easier,
  18 as well as for tracking completed grant-funded work.
  19
  20 It is **extremely** important to link the new bug to previous ones. As Luke
  21 mentioned on [this bug](https://bugs.libre-soc.org/show_bug.cgi?id=1139#c3),
  22 "it is a mandatory project requirement that the graph from any bug
  23 contain all other bugs (one "Group")".
  24
  25 The primary reason for this is to ensure bugs don't get buried and lost,
  26 and will aid those tackling similar problems at a later time.
  27
  28 Also, for project management and financing purposes, it helps developers
  29 to keep an up-to-date list of their tasks.
  30
  31 ##How to raise issues
  32
  33 1. Create a bug report.
  34 2. Add in any links from the mailing list or IRC logs to the bug report for back tracking
  35   (this is mandatory). Also fill in the URL field if there is a relevant wiki page.
  36 3. CC in relevant team members
  37 4. make absolutely sure to fill in "blocks", "depends on" or "see also" so that the
  38    bug is not isolated (otherwise bugs are too hard to find if isolated from everything else)
  39 5. Ping on IRC to say a bug has been created
  40 6. Unless you know exactly which milestone to use, leave blank initially. This
  41 also applies when editing milestone, budget parent/child, toml fields. See
  42 section [[HDL_workflow#Task management guidelines]] further down.
  43 7. After setting the milestone, it is **absolutely required** to run
  44 [budget-sync](https://git.libre-soc.org/?p=utils.git;a=blob;f=README.txt;hb=HEAD),
  45 as it will point out any discrepancies. The budget allocations will be used for
  46 accounting purposes and **MUST** be correct. *Note you can only get paid for
  47 stuff done **after the nlnet grant is approved** (before the MOU is signed)*
  48
  49 If a developer ever needs to check which bugs are assigned to them, go to the
  50 Libre-SOC bug tracker
  51 [advanced search page](https://bugs.libre-soc.org/query.cgi?format=advanced),
  52 and in the "Search by People" section, check "Bug Assignee" and "contains"
  53
  54 # Adding sub-tasks to tasks under existing milestone
  55
  56 * notify Michiel and the relevant NNNN-NN@nlnet.nl team of
  57   advance notice of intent to add new sub-tasks, cc'ing bob
  58   goudriaan
  59   - confirm with them that this is NOT a change in the AGREED
  60     MILESTONE BUDGETs, because it is just sub-task allocation.
  61   - confirm that they are happy to add the sub-tasks to the MoU
  62     (this needs approval of bob goudriaan)
  63 * *re-generate* the JSON file
  64 * make a DIFF against the *PREVIOUS* JSON file
  65 * create a MANUAL report/summary of "changes" that
  66   NLnet may easily action
  67   - "add the following task X to parent Y of amount W",
  68   - and if any: "change parent Z available amount to V as a WRAPUP")
  69   (this latter is because occasionally there are subtasks **not**
  70    totalling the full parent amount, usually because a summary
  71    report is needed. Michiel and I privately agreed to call
  72    this "wrapup")
  73 * obtain a confirmation that this has been actioned
  74 * **double-check** that the RFP database correctly matches the new
  75   bugzilla status.
  76
  77 PLEASE NOTE: YOU CANNOT ACTION THE ABOVE UNDER THE FOLLOWING CIRCUMSTANCES
  78
  79 1. to make a change to the actual budgetary amounts of the
  80    Grant Milestones, without written authorization from Bob
  81    and Michiel. a DIFFERENT PROCEDURE is needed.
  82    this is because NLnet had to go through a 3rd party Verification
  83    Process with the European Union: changing the amounts without
  84    consent is therefore tantamount to fraud.
  85
  86 2. if there has been an RFP already submitted under a given Milestone,
  87    it becomes NO LONGER POSSIBLE to change the JSON file in NLnet's
  88    system because it is too complex.
  89
  90    there is one Grant in this complex situation: bug #690, the crypto
  91    grant.  it is made much more complex because it *pre-dates* NLnet's
  92    current RFP system, where RFPs were submitted by EMAIL and there
  93    are manual records not fully integrated into the database.
  94
  95 also note: as the addition of sub-tasks *requires a change to the MOU*
  96 it should NOT be taken lightly, i.e. should not be arbitrarily done
  97 one by one, but only in "batches".
  98
  99 considerable care therefore has to be taken to ensure that NLnet are
 100 not overloaded, nor that the EU Auditor is given grounds to become
 101 "suspicious" because of a dozen or more alterations to the MOU.
 102 and write your nickname (i.e. andrey etc.).