[llvm-dev] [clangd-dev] Subprojects, GitHub, and the Monorepo

[Renato Golin via llvm-dev]

On Mon, 22 Oct 2018 at 09:39, Manuel Klimek <klimek at google.com> wrote:
> Have the projects under LLVM grown diverse enough that one solution doesn't fit all any more, at least for docs & bug tracking?

That's is a good question, and one that amidst the constant pull to
look at it recently, has made me think about, too.

> The reason clangd lives in LLVM is a technical one; the user base in terms of who interacts with the community is very different;

I imagine this is the same reason to keep llgo inside the tree. How
good the technical side of it is is less important when interacting
with the sub-community.

> we want clangd bugs to be reported by folks who would never file a compiler bug (because from their point of view, it's always a bug in your own code ;).

I think that's true for all projects. I don't think we should ever
start from the assumption that the user is wrong. It could be problems
in clarity, for ex. documentation, expectation, legacy, which is
different from being plain wrong.

> Bug reports for clangd are by their nature less "heavy", because clangd is not a precise enforcer of a standard, but a little helper to the programmer who is judged by providing value, not whether it is right (according to some standard). For example, "these 2 completions are in the wrong order" is a useful and valid bug report.
>
> I'd agree that we can take it slowly if this was just about making our own lives easier. This is about the lives of our users, though, where I'd argue that making it more frustrating for them is ultimately going to make it hard to deliver a compelling product.

I agree.

Some people consider open source software as "no one's land" where the
users have to fight to get support. I think that's 20 years too old.

But I also agree that not everyone knows how to be supportive (I often
struggle with it), and not responding makes users as angry as
responding badly.

Some users also react badly when shown to be wrong (standards, maths,
expectation, legacy, or just plain projects' own decisions), and that
puts off developers from helping again.

I am, however, quite happy to let those who can, to do the best way
possible, even if that means I'll have to click one or two more links
on my side. :)

If that means more than one tracking system (one per groups of
projects, multi-tiered, etc), so be it, as long as there are people
willing to maintain it and doing a good job at it.

-- 
cheers,
--renato