From: Andrey Miroshnikov Date: Mon, 13 Nov 2023 20:36:07 +0000 (+0000) Subject: Change _ to * X-Git-Url: https://git.libre-soc.org/?a=commitdiff_plain;h=583a0852053dde49ffadf56f629729c3fada3228;p=libreriscv.git Change _ to * --- diff --git a/HDL_workflow/libresoc_bug_process.mdwn b/HDL_workflow/libresoc_bug_process.mdwn index 67adca24e..824586709 100644 --- a/HDL_workflow/libresoc_bug_process.mdwn +++ b/HDL_workflow/libresoc_bug_process.mdwn @@ -164,7 +164,7 @@ to help determine the scope of the work involved. Given the scale of this project and the critical reliance on certain parts of it (such as devscripts, ISA csv files, ISACaller, etc.) on the work done by the team, it is extremely important to raise any proposed changes and/or -improvements, and to wait for feedback _before_ implementing said changes. +improvements, and to wait for feedback *before* implementing said changes. Going forward, we all need to keep this in mind when working on critical parts of the codebase. @@ -175,15 +175,15 @@ focus on: 1. Completing tasks under grant budget 2. Make small, incremental changes which keep the overall codebase functional. 3. When coming up with fixes or improvements which are intrusive to the - _current_ workflow (which may slow the team down from completing tasks + *current* workflow (which may slow the team down from completing tasks under grant budget), assign them to 'Future' milestone for grant applications going forward. Why these three points? 1. Work that cannot be related to grant sub-tasks (even if indirectly, by - bringing us closer to eventual completion), should be put aside _until - future funding is secured/confirmed_. + bringing us closer to eventual completion), should be put aside *until + future funding is secured/confirmed*. 2. Small changes make it easier and quicker to find mistakes. That's one of the reasons Luke has specified on [[/HDL_workflow]] to stick to small commits. *(Andrey: I need to improve on this myself)* @@ -203,7 +203,7 @@ Why these three points? - If you discover a problem in code, raise a bug report, and use a corresponding 'importance' setting depending on how serious you perceive the -issue to be. This will start a _discussion_. +issue to be. This will start a *discussion*. **No work is to be started yet.** @@ -238,7 +238,7 @@ an issue at all, it is to be set to either of the following: see the discussion before the issue disappears. - Once the issue has been discussed and determined to be critical to current -grant sub-task/s, and budget considered, _then_ work can proceed in a separate +grant sub-task/s, and budget considered, *then* work can proceed in a separate branch. Only after fixes have been confirmed to keep the CI tests passing, can they be rebased (to keep commit history) into the master branch.