[libre-riscv-dev] Documenting the SOC tree Repository

Luke Kenneth Casson Leighton lkcl at lkcl.net
Sun May 3 00:24:38 BST 2020


On Saturday, May 2, 2020, Yehowshua <yimmanuel3 at gatech.edu> wrote:

> Also - I’d like to clean up the decoder a bit. I’ll go ahead and make a
> branch and push to that


i really do not like branches.  please, really: do not use them except
under absolute dire critically necessary circumstances.  i documented thus
in HDL_workflow.


> I’ll have you guys review periodically.


please, follow the HDL_workflow.  it is there for a reason.

use the unit tests, make sure anything you do works 100%.  work
incrementally (5 to 15 lines per commit is perfectly acceptable) and commit
directly to the master branch.  do not be afraid to make 20 to 40 commits
*a day*.  untested code that is comoletely unused is perfectly fine.

yes it means that you really do have to be certain that what you commit is
going to work, and that's the whole point.

by working in master, you *have* to be strict, keep to small changes, and
keep constantly in touch.

not "periodically commit because i'm hiding what i am working on because i
don't want anyone to see it in case they criticise it because it's neither
perfect nor complete"

that is *not* collaboration!

so if you find that you are not 100% confident, because a unit test is
missing, write and commit the unit test, *then* make the incremental
change, make sure the unit tests pass, and then git push.

this is described on http://libre-soc.org/HDL_workflow

if you absolutely must make large changes, they can be done by writing the
leaf nodes of alternatives, then when it comes to changing the code that
uses the alternatives, writing classes with alternative implementations
that are *dynamically chosen* at runtime, through a config file and so on.

there's other techniques as well.

l.



-- 
---
crowd-funded eco-conscious hardware: https://www.crowdsupply.com/eoma68


More information about the libre-riscv-dev mailing list