From: Luke Kenneth Casson Leighton <lkcl@lkcl.net>
To: Libre-RISCV General Development <libre-riscv-dev@lists.libre-riscv.org>
Subject: Re: [libre-riscv-dev] Documenting the SOC tree Repository
Date: Sun, 3 May 2020 00:24:38 +0100
Message-ID: <CAPweEDyMasGzb-jqu1nhrsddW0D4DNsAD0v100s17OMJ8-BhTA@mail.gmail.com> (raw)
In-Reply-To: <15B29048-8343-4683-9724-85A5307A6E1B@gatech.edu>
On Saturday, May 2, 2020, Yehowshua <yimmanuel3@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
_______________________________________________
libre-riscv-dev mailing list
libre-riscv-dev@lists.libre-riscv.org
http://lists.libre-riscv.org/mailman/listinfo/libre-riscv-dev
next prev parent reply index
Thread overview: 8+ messages / expand[flat|nested] mbox.gz Atom feed top
2020-05-02 3:09 Yehowshua
2020-05-02 4:40 ` Luke Kenneth Casson Leighton
2020-05-02 4:42 ` Yehowshua
2020-05-02 20:59 ` Yehowshua
2020-05-02 23:24 ` Luke Kenneth Casson Leighton [this message]
2020-05-03 0:08 ` Yehowshua
2020-05-03 0:09 ` Yehowshua
2020-05-03 0:21 ` Luke Kenneth Casson Leighton
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=CAPweEDyMasGzb-jqu1nhrsddW0D4DNsAD0v100s17OMJ8-BhTA@mail.gmail.com \
--to=lkcl@lkcl.net \
--cc=libre-riscv-dev@lists.libre-riscv.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Libre RISC-V Mailing list Archives (accessible via public-inbox)
Archives are clonable: git clone --mirror https://inbox.libre-soc.org/libre-riscv-dev
Example config snippet for mirrors
AGPL code for this site: git clone https://public-inbox.org/public-inbox.git