From da5c7c7ce57b4ea0d5bf460ceb006b848537b733 Mon Sep 17 00:00:00 2001 From: lkcl Date: Thu, 23 Jan 2020 21:08:30 +0000 Subject: [PATCH] --- HDL_workflow.mdwn | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/HDL_workflow.mdwn b/HDL_workflow.mdwn index 537efc6ee..eb4a51b79 100644 --- a/HDL_workflow.mdwn +++ b/HDL_workflow.mdwn @@ -185,7 +185,7 @@ regarding the above it is important that you read, understand, and agree to the for actual code development: * **do not commit autogenerated output**. write a shell script and commit that, or add a Makefile to run the command that generates the output, but **do not** add the actual output of **any** command to the repository. ever. this is really important. even if it is a human-readable file rather than a binary object file. -* if the command needed to create any given autogenerated output is not currently in the list of kniwn project dependencies, first consult on the list if it is okay to make that command become a hard dependency of the project (hint: java, node.js php and .NET commands may cause delays in response time due to other list participants laughing hysterically), and after a decision is made, document the dependency and how its source code is obtained and built (hence why it has to be discussed) +* if the command needed to create any given autogenerated output is not currently in the list of known project dependencies, first consult on the list if it is okay to make that command become a hard dependency of the project (hint: java, node.js php and .NET commands may cause delays in response time due to other list participants laughing hysterically), and after a decision is made, document the dependency and how its source code is obtained and built (hence why it has to be discussed) * if you find yourself repeating commands regularly, chances are high that someone else will need to run them, too. therefore, put them into a .sh shell script (and/or a Makefile) and document them at the very minimum in README or INSTALL.txt or somewhere in a docs folder as appopriate. if unsure, ask on the mailing list for advice. * plan in advance to write not just code but a full test suite for that code. **this is not optional**. large python projects that do not have unit tests **FAIL**. * edit files making minimal *single purpose* modifications (even if it involves multiple files. Good extreme example: globally changing a function name across an entire codebase is one purpose, one commit, yet hundreds of files). -- 2.30.2