add stub meeting page, TODO
[libreriscv.git] / HDL_workflow.mdwn
index b598d01a71375ce4e30fc5df8dd7d2dc6779583c..d9e570ba4ddd899fc9b11a8b425a8222f0e2a2e1 100644 (file)
@@ -126,6 +126,8 @@ send this to Spam" option.
 
 ## Bugtracker
 
+* **LibreSOC bug/task process**: [[libresoc_bug_process]]
+
 bugzilla. old and highly effective. sign up in the usual way. any
 problems, ask on the list.
 
@@ -133,6 +135,8 @@ Please do not ask for the project to be transferred to github or other
 proprietary nonfree service "because it's soooo convenient", as the
 lions are getting wind and gout from overfeeding on that one.
 
+one.
+
 ## ikiwiki
 
 Runs the main libre-soc.org site (including this page). effective,
@@ -389,7 +393,7 @@ flows.
 prior to installing any further python-based Libre-SOC HDL repositories.
 If "pip3 list" shows that nmigen has been auto-installed please remove it**
 
-[nmigen](https://nmigen.info/) may be installed as follows:
+[nmigen](https://m-labs.hk/gateware/nmigen/) may be installed as follows:
 
 * mkdir ~/src
 * cd !$
@@ -413,6 +417,7 @@ In the meantime, sfpy can be built as follows:
 
     git clone --recursive https://github.com/billzorn/sfpy.git
     cd sfpy
+    git apply /path/to/ieee754fpu/sfpy.patch
     cd SoftPosit
     git apply ../softposit_sfpy_build.patch
     git apply /path/to/ieee754fpu/SoftPosit.patch
@@ -898,6 +903,55 @@ easy-to-find message, it cannot even be located, and once found, if the
 commit confuses several unrelated changes, not only the diff is larger
 than it should be, the reversion process becomes extremely painful.
 
+### PHP-style python format-strings
+
+As the name suggests, "PHP-style" is not given as a compliment.
+Format-strings - `f"{variable} {pythoncodefragment}" are a nightmare
+to read.  The lesson from PHP, Zope and Plone: when code is embedded,
+the purpose of the formatting - the separation of the format from
+the data to be placed in it - is merged, and consequently become
+unreadable.
+
+By contrast, let us imagine a situation where 12 variables need to
+be inserted into a string, four of which are the same variablename:
+
+     x = "%s %s %s %s %s %s %s %s %s %s %s %s" % (var1, var2, var3,
+                                                  var3, var4, var2,
+                                                  var1, var9, var1,
+                                                  var3, var4, var1)
+
+This is just as unreadable, but for different reasons.  Here it *is*
+useful to do this as:
+
+     x = f"{var1} {var2} {var3}" \
+         ...
+         f"{var3} {var4} {var1}"
+
+As a general rule, though, format-specifiers should be strongly
+avoided, given that they mix even variable-names directly inside
+a string.
+
+This additionally gives text editors (and online web syntax
+highlighters) the opportunity to colour syntax-highlight the
+ASCII string (the format) from the variables to be inserted *into*
+that format.  gitweb for example (used by this project) cannot
+highlight string-formatted code.
+
+It turns out that colour is processed by the **opposite** hemisphere
+of the brain from written language.  Thus, colour-syntax-highlighting
+is not just a "nice-to-have", it's **vital** for easier and faster
+identification of context and an aid to rapid understanding.
+
+Anything that interferes with that - such as python format-strings -
+has to take a back seat, regardless of its perceived benefits.
+
+**If you absolutely must** use python-format-strings, **only** do
+so by restricting to variables.  Create temporary variables if you
+have to.
+
+    y = '/'.join(a_list)
+    x = f"{y}"
+
 ### PEP8 format
 
 * all code needs to conform to pep8.  use either pep8checker or better
@@ -1109,6 +1163,42 @@ Simply mark it with an appropriate
 preferably with a link to a URL in the [bugtracker](https://bugs.libre-soc.org/)
 with further details as to why the unit test should not be run.
 
+# Task management guidelines
+
+1. Create the task in appropriate "Product" section with appropriate
+  "Component" section. Most code tasks generally use "Libre-SOC's
+  first SOC".
+2. Fill in "Depends on" and "Blocks" section whenever appropriate.
+   Also add as many related ("See Also") links to other bugreports
+   as possible. bugreports are never isolated.
+3. Choose the correct task for a budget allocation. Usually the parent
+  task is used.
+4. Choose the correct NLnet milestone. The best practice is to check
+  the parent task for a correct milestone.
+5. Assign the budget to the task in `"USER=SUM"` form, where "USER"
+  corresponds to your username and "SUM" corresponds to the actual
+  budget in EUR. There may be multiple users.
+6. When the task is completed, you can begin writing an RFP.
+   **DO NOT submit it without explicit authorisation and review**.
+   Leave out your bank and personal address details if you prefer
+   when sending to the Team Manager for review.
+7. Once the RFP is written, notify the Team Manager and obtain their
+   explicit approval to send it.
+8. Once approval is received and the RFP sent, update the `"USER=SUM"`
+  field to include the submitted date:
+  `"USER={amount=SUM, submitted=SDATE}"`. The SDATE is entered in
+  `YYYY-MM-DD` form.
+9. Once the task is paid, again notify the Team Manager (IRC is fine),
+  and update `"USER={amount=SUM, submitted=SDATE}"`
+  to `"USER={amount=SUM, submitted=SDATE, paid=PDATE}"`. The PDATE is
+  entered in `YYYY-MM-DD` form, too.
+
+Throughout all of this you should be using budget-sync to check the
+database consistency
+<https://git.libre-soc.org/?p=utils.git;a=blob;f=README.txt;hb=HEAD>
+
+[[!img bugzilla_RFP_fields.jpg size=640x ]]
+
 # TODO Tutorials
 
 Find appropriate tutorials for nmigen and yosys, as well as symbiyosys.