[libre-riscv-dev] monorepo

[Luke Kenneth Casson Leighton]

On Wed, May 20, 2020 at 7:43 PM Jacob Lifshay <programmerjake at gmail.com> wrote:

> what about if we have a monorepo where we have an automatically updated
> read-only git mirrors for the subdirectories that can be used independently
> as well as documenting that everywhere it's relevant? That would quite
> explicitly give the message that those subdirectories are intended to be
> usable separately from the rest of our code.

again: bear in mind that this is a non-essential administrative task -
one that even the discussion itself is a distraction.

to evaluate this idea - its viability to ensure that commits for the
correct portions of the monorepo are preserved - is itself a
distraction.

to *code* such a system is itself a distraction.

and also not a good idea.  how do you preserve commit history when two
files in different repo-mirrors are under the same commit?

answer: you don't.

question: how do you ensure that the commit checksum is the same
across the two repositories?

answer: you don't.

git mirrors are *exact* mirrors.

all of this is a serious distraction and we do not need distractions right now.

i have been doing software development now for almost 25 years: please
trust me when i say that a monorepo is detrimental to our project's
long-term goals.

for the "inconvenience" we have to tolerate, we end up with
strategically much more useful code, with CLEAR delineation and
boundaries between each repository.

please can we stop discussing this: the answer is no, and having to
explain it each and every time is a major distraction.


> > when you have time, look up the nightmare of freeswitch ignoring standard
> > development practices when it comes to dependency management.
> >
>
> I'm not advocating for us to have all external dependencies be a part of
> our monorepo, only the code we are actively developing and is closely
> related: nmutil, soc, ieee754fpu,

closely related only because we happen to be the only users of these
repositories... *at the moment*.

> and probably the layout code.

we discussed this with jean-paul, he advises very strongly not to do that.


l.