search for: megarepo

...ple is: > > - Fork the repo that you’re interested in from the LLVM GitHub organisation > - Make your changes > - Send pull requests for anything that you think is of interest to upstream > I understand this, but why isn't "the repo you're interested in" just the megarepo (or monorepo) where every LLVM project resides? > This makes the barrier to entry for sending code back upstream *much* lower than it currently is, to the benefit of all. If the alternative is: > > - Fork a read-only repo that you’re interested in from the LLVM GitHub organisation >...

On 29 Jul 2016, at 12:35, Dean Michael Berris <dean.berris at gmail.com> wrote: > > I understand this, but why isn't "the repo you're interested in" just the megarepo (or monorepo) where every LLVM project resides? Your assumption is a downstream user of LLVM. As previously pointed out, we have downstream users of libc++ and the sanitizer runtimes who compile with gcc. For a downstream user of LLVM, the cost of getting everything else is in the noise. For a...

> On 29 Jul 2016, at 21:58, David Chisnall <david.chisnall at cl.cam.ac.uk> wrote: > > On 29 Jul 2016, at 12:35, Dean Michael Berris <dean.berris at gmail.com> wrote: >> >> I understand this, but why isn't "the repo you're interested in" just the megarepo (or monorepo) where every LLVM project resides? > > Your assumption is a downstream user of LLVM. As previously pointed out, we have downstream users of libc++ and the sanitizer runtimes who compile with gcc. For a downstream user of LLVM, the cost of getting everything else is in the nois...

On 29 July 2016 at 13:04, Dean Michael Berris via llvm-dev <llvm-dev at lists.llvm.org> wrote: > Is it really impossible to just build non-LLVM dependent versions of libc++ or the sanitiser runtimes if they reside in one git megarepo? The more intricate the relationship between the components, the less we'll test for the alternative solutions. My use is solely from a toolchain point of view. For me, having it all in one blob would be perfect, and I would never have to worry about integrations again. (in a perfect world, e...

...vid Chisnall <david.chisnall at cl.cam.ac.uk> > wrote: > > > > On 29 Jul 2016, at 12:35, Dean Michael Berris <dean.berris at gmail.com> > wrote: > >> > >> I understand this, but why isn't "the repo you're interested in" just > the megarepo (or monorepo) where every LLVM project resides? > > > > Your assumption is a downstream user of LLVM. As previously pointed > out, we have downstream users of libc++ and the sanitizer runtimes who > compile with gcc. For a downstream user of LLVM, the cost of getting > everyt...

On 29 Jul 2016, at 05:11, Mehdi Amini via llvm-dev <llvm-dev at lists.llvm.org> wrote: > > What I meant by “different problem" is that “downstream users” for instance don’t need to commit, that makes their problem/workflow quite different from an upstream developer (for instance it is fairly easy to maintain a read-only view of the existing individual git repo currently on

> On Jul 28, 2016, at 7:32 PM, Lang Hames <lhames at gmail.com> wrote: > > Hi Mehdi, > > This a narrow view IMO: the criteria #1 Chris mentioned to include projects in the monorepo was " must be tightly coupled to specific versions”. > It means that even with the test suite (and possibly some runtime) out of the monorepo, all the software that is tightly coupled

Hi Duncan, > […] > 2. Those working on projects *outside* the monolithic repo will get the downsides of both: a monolithic repo that they are only using parts of, and multiple repos that are somehow version-locked. > > 3. For many (most?) developers, changing to a monolithic git repo is a *bigger* workflow change than switching to separate git repos. Many people (and at least some