[Libre-soc-dev] project development policy for commits
Luke Kenneth Casson Leighton
lkcl at lkcl.net
Thu Dec 9 10:18:36 GMT 2021
i woke up this morning and had to scramble to fix a bug that had been
introduced, otherwise everyone who puled the repositories would find
that nothing worked.
jacob: it is absolutely critical that you pay far more attention to what you
are doing than you are doing at the moment.
you arbitrarily committed code that, *if you had run the unit tests as you
are supposed to do*, you would have found out BEFORE pushing the code
and distributing broken code to absolutely everybody, stops absolutely
every single one of the primary unit tests from working.
it is *your responsibilty* to ensure that the unit tests are functional at
dropping a bugreport into the system without investigating it or appreciating
the seriousness of taking action that prevents and prohibits everyone else
from doing work is deeply irresponsible, and violates the Libre-SOC Charter
by not taking responsibility for your mistakes.
please can you re-read the HDL_workflow sections on commit policy
and procedure, paying attention to running of unit tests.
1) run relevant unit tests BEFORE a git push. (it's sort-of fine, not exactly,
to commit code that "breaks", as long as you then follow up with commits
that fix it and DO NOT push "broken" code. this breaks git bisect so should
2) if you subsequently find that you caused an error PLEASE DO NOT PUSH
A BUGREPORT AND LEAVE IT TO SOMEONE ELSE
instead: please do absolutely everything that you can, as quickly as possible,
to either revert - entirely - the broken code - or to fix it as
quickly as you can.
in this particular case, you should have either:
a) set regreduce=False everywhere
b) set regreduce=False locally for the SPR module
c) done a "git revert"... and *then* raised the SPR bugreport.
because you had not done that, you terminated all and any possibility for
people *without sufficient experience* or knowledge of the codebase from
being able to run about a dozen critical unit tests.
i then had to scramble this morning and sort out your mess, which makes
changing of low-level code has to be done with EXTREME CAUTION,
and expecting someone else to clean up after you is really not on.
please take this on board and learn from the experience, that the
incremental project development practices i put in place are there for
extremely good reasons: to make cooperative development of such a
large project possible.
crowd-funded eco-conscious hardware: https://www.crowdsupply.com/eoma68
More information about the Libre-soc-dev