llvm dev - Jul 2016 - [RFC] One or many git repositories?

Monolithic is trying to solve the wrong problem - it's that simple.
Any discussion or attempt to coddle those who think it's necessary is
a waste of time. #dictator

As part of any potential migration, everyone involved must start to
accept certain changes, (large or small) to the workflow. The big
challenge here isn't technical, it's mindset. It's convincing any
group of people who object that it won't be as painful to them as they
think. (I hope this is a true statement)

#if - there's a group of people are : dogmatic, stubborn and
unreasonable - others outside that group should decide how to deal
with them: ignore, coddle, placate or other.

I don't think there's a perfect technical solution to make everyone
happy - I think focusing on the social engineering will be an equal or
greater importance. (herding cats)

With the survey - I guess you could include some level of objection
like - strongly against and over my dead body type reactions are
probably the most to be cautious about. Anyone surveyed who fall in
the middle or slightly left/right can be seen as "flexible". If it
turns out that they survey shows only 1-5 people with extreme views
and 100 people with moderate or flexible views - those are hard
numbers. From there decisions can be made and long unending threads
like this can die - so we can all get back to reading more important
things.



On Fri, Jul 22, 2016 at 12:49 AM, Renato Golin via llvm-dev
<llvm-dev at lists.llvm.org> wrote:
> Question:
>
> Which projects do we put under this monolithic repository?
>
> SVN has about 42 projects, some of them dead, some of them in life support.
>
> So far, being "an upstream repository" meant being inside the
LLVM SVN
> server. We'll change that to "being inside the monolithic LLVM
> repository". But this can become huge, and not all projects
"ink" back
> to LLVM.
>
> An alternative would be to just have some core projects in the
> monolithic and everything else as separate, but then what's core?
>
> As a back-of-the-envelope, I suggest: llvm, clang, clang-tools-extra,
> compiler-rt, libc++, libc++abi, libunwind, test-suite.
>
> I'm thinking LLD and LLDB could remain out, but I don't think it
would
> be too weird for them to be in...
>
> Anything else? Less?
>
> cheers,
> --renato
> _______________________________________________
> LLVM Developers mailing list
> llvm-dev at lists.llvm.org
> http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev

On 7/21/16 11:03 AM, C Bergström via llvm-dev wrote:
> Monolithic is trying to solve the wrong problem - it's that simple.
> Any discussion or attempt to coddle those who think it's necessary is
> a waste of time. #dictator
Christopher,

AFAICT, you haven't explained *why* it is the wrong problem. Mind 
elaborating on that?


Jon

p.s: edicts, appeals to authority, and ad hominems are not useful for 
discussion. Doing that, and following up with "#dictator" further 
solidifies that you know your own argument is b-s.... please stop.

-- 
Jon Roelofs
jonathan at codesourcery.com
CodeSourcery / Mentor Embedded

FWIW, like David Chisnall, we (Azul) have a problem with rewriting
history.  Our LLVM fork has O(100) changes diverging from upstream
(though our branching structure is simple), and keeping all of that
history is important.

What do people think of having one (or a set of) merge commit(s)
merging in the non-llvm projects that will be part of the new
monorepo?  That's the only technique I can think of that will preserve
history for downstream users by construction.

-- Sanjoy


On Thu, Jul 21, 2016 at 10:44 AM, Jonathan Roelofs via llvm-dev
<llvm-dev at lists.llvm.org> wrote:
>
>
> On 7/21/16 11:03 AM, C Bergström via llvm-dev wrote:
>>
>> Monolithic is trying to solve the wrong problem - it's that simple.
>> Any discussion or attempt to coddle those who think it's necessary
is
>> a waste of time. #dictator
>
>
> Christopher,
>
> AFAICT, you haven't explained *why* it is the wrong problem. Mind
> elaborating on that?
>
>
> Jon
>
> p.s: edicts, appeals to authority, and ad hominems are not useful for
> discussion. Doing that, and following up with "#dictator" further
solidifies
> that you know your own argument is b-s.... please stop.
>
> --
> Jon Roelofs
> jonathan at codesourcery.com
> CodeSourcery / Mentor Embedded
>
> _______________________________________________
> LLVM Developers mailing list
> llvm-dev at lists.llvm.org
> http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev


-- 
Sanjoy Das
http://playingwithpointers.com