| 1 |
Hi, |
| 2 |
|
| 3 |
As you may have noticed, I'm practically maintaining LLVM all by myself. |
| 4 |
This is a really tedious, time consuming and ungrateful task, and I'm |
| 5 |
pretty close to burnout. I'd really appreciate some help. |
| 6 |
|
| 7 |
The problem with LLVM that it's a really huge, rapidly moving forward |
| 8 |
(and breaking things) project. It needs frequent testing as regressions |
| 9 |
happen frequently, and we have a good chance of having somebody else fix |
| 10 |
it if we report them early. At the same time, testing takes a lot of |
| 11 |
time. While ccache is pretty much a must, it doesn't help much long |
| 12 |
term as the code is changing frequently and invalidating the cache. |
| 13 |
|
| 14 |
On top of this, there's almost-overlapping release process and Gentoo |
| 15 |
slotting that's working so-so at best. After I've pushed LLVM 13.0.1 |
| 16 |
final, I've had to immediately start testing 14.x and barely managed to |
| 17 |
get some fixes in before rc1. Now 14.0.0 is expected soon, |
| 18 |
simultaneously major changes are happening on the main branch |
| 19 |
(i.e. 15.x) that also need testing and adjusting the ebuilds to. |
| 20 |
|
| 21 |
I barely manage to keep up with amd64 multilib. Other arches are likely |
| 22 |
to be broken. Some specific projects that need help are: |
| 23 |
|
| 24 |
1. Compiler-RT (particularly sanitizers, fuzzer etc.) -- they break |
| 25 |
quite often on glibc upgrades. Miraculously, right now 13.0.1 |
| 26 |
and 14.0.0 are clean right now but I'm pretty sure we'll see a new glibc |
| 27 |
release soon and they're going to require fixing again. |
| 28 |
|
| 29 |
2. OpenMP -- there are many test regressions on every release, and 14.x |
| 30 |
is particularly bad. I have no clue about this package, the test output |
| 31 |
is usually cryptic and I don't really have the time to look into it. |
| 32 |
Honestly, at this point I would gladly have last rited it if it hadn't |
| 33 |
had revdeps. |
| 34 |
|
| 35 |
3. LLDB -- while it mostly works and I've managed to fix the worst of |
| 36 |
it, I still haven't managed to get the test suite fully working. What's |
| 37 |
even worse, the test runner just hangs at the very end and I have |
| 38 |
no clue why or how to debug that. |
| 39 |
|
| 40 |
Plus the generic stuff: |
| 41 |
|
| 42 |
4. Testing LLVM 15.x periodically, bisecting, reporting bugs early. |
| 43 |
I can help triaging and reporting the bugs but at least I'd need |
| 44 |
somebody else to run the builds more often than I can. |
| 45 |
|
| 46 |
5. Testing LLVM 14.x, 15.x on non-amd64 architectures (including x86 |
| 47 |
builds -- not all LLVM components are multilib) and reporting bugs. |
| 48 |
Unfortunately, this part may require actually providing patches. |
| 49 |
|
| 50 |
6. Work on setting up and configuring a buildbot for Gentoo LLVM builds. |
| 51 |
This is some effort and I don't have the time to learn how to do that. |
| 52 |
You'll probably need to set up a local instance and figure out how to |
| 53 |
set our builds before submitting anything upstream; in my experience |
| 54 |
they aren't very responsive to buildbot changes, so ideally we need to |
| 55 |
flesh out any problems early. |
| 56 |
|
| 57 |
Yes, that's a lot of work. I can't do it all myself, I'm already doing |
| 58 |
too much and this is having negative impact on my health. I really need |
| 59 |
help with this. |
| 60 |
|
| 61 |
Disclaimer: I've been doing some LLDB-related paid work in the past. |
| 62 |
However, this work wasn't Gentoo-related and if anything, it required me |
| 63 |
to spend my CPU time on work and not testing LLVM for Gentoo. |
| 64 |
|
| 65 |
-- |
| 66 |
Best regards, |
| 67 |
Michał Górny |
Archives