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

[Renato Golin via llvm-dev]

On Sun, 21 Oct 2018 at 02:39, Duncan P. N. Exon Smith via llvm-dev
<llvm-dev at lists.llvm.org> wrote:
>> Yes, everyone has a github account -- but I think everyone could also use bugzilla easily enough, if we add a "Login with github" button. I would like someone to volunteer to work on getting bugzilla patched with that functionality. (Someone, please volunteer!)

I'd only put the effort if we aim to continue it for a long time after
the GitHub migration. I don't mind bugzilla, github issues, or any
other, but migrations are always messy and we're already doing a big
one.

Adding login with GitHub won't stop spam and will have bad
integration, trouble of managing previous emails from older posts for
the same person, etc.

>  - our users still won't know how to use bugzilla

Does anyone?

>  - bolted-on github account support is second-class (e.g. cc lists are still email addresses, @mentions don't work)

Yup.

>  - bugzilla's UI is atrocious (hard to summarize; happy to go into this if there's real disagreement)

Bugzilla is 20 years old. It was done before the dot-com crash when
every click was a new page, with all the context issues from the
times, and it's still basically the same.

For the same 20 years, I have used numerous tracking systems and all
of them are bad in some way. I'm sure if/when we get to use GitHub's
we'll realise that tags just don't scale, or that we can't separate
the projects correctly, or that we would have done something silly in
the beginning and not be able to move later one.

Rushing moving away from bugzilla is not a wise decision, IMHO.

> I don't think anyone likes or wants to use or administer Bugzilla.  It's just what we have right now and we don't as a community have bandwidth to figure out what to do until we've made the repository move.  When we have bandwidth, we should just fix this across the project.  Probably after we move the repo; possibly with GitHub issues, but I think it should be the same across the project.

Agreed.

> I can see how having a completely separate bug tracker could help a little, but I'm skeptical there are major benefits over putting each tool that has a distinct userbase at the top-level.
> - clang
> - clangd
> - (whatever else)
> - llvm

For starter, having it all separate would make it harder to move bugs
around when we realise it's not a clang bug but a back-end one, or a
library issue.

My personal opinion is that we should not assume GitHub issues is the
way to go just because we're moving to GitHub for code. GitHub is
portable enough, and mainstream enough, that there are a vast number
of products out there that plug into it seamlessly.

We can even find that we don't need one single tool, but a number of
smaller ones, different for bugs, releases, major features, projects,
administration, etc. There is no technical reason for us to bundle it
all in one single tool.

That's what we've done with bugzilla (with sub-projects and meta bugs
etc) because we had no other option. I'd hate to rush a bug-tracking
move into another end-point and then have to have the same
conversation 5 years from now.

We have lived with bugzilla for the past decade, we can live with it
for another year.

cheers,
--renato