| 1 |
On Fri, 2022-02-11 at 21:19 +0200, Joonas Niilola wrote: |
| 2 |
> On 11.2.2022 1.36, Michał Górny wrote: |
| 3 |
> > Hi, |
| 4 |
> > |
| 5 |
> > As you may have noticed, I'm practically maintaining LLVM all by myself. |
| 6 |
> > This is a really tedious, time consuming and ungrateful task, and I'm |
| 7 |
> > pretty close to burnout. I'd really appreciate some help. |
| 8 |
> > |
| 9 |
> > The problem with LLVM that it's a really huge, rapidly moving forward |
| 10 |
> > (and breaking things) project. It needs frequent testing as regressions |
| 11 |
> > happen frequently, and we have a good chance of having somebody else fix |
| 12 |
> > it if we report them early. At the same time, testing takes a lot of |
| 13 |
> > time. While ccache is pretty much a must, it doesn't help much long |
| 14 |
> > term as the code is changing frequently and invalidating the cache. |
| 15 |
> > |
| 16 |
> > On top of this, there's almost-overlapping release process and Gentoo |
| 17 |
> > slotting that's working so-so at best. After I've pushed LLVM 13.0.1 |
| 18 |
> > final, I've had to immediately start testing 14.x and barely managed to |
| 19 |
> > get some fixes in before rc1. Now 14.0.0 is expected soon, |
| 20 |
> > simultaneously major changes are happening on the main branch |
| 21 |
> > (i.e. 15.x) that also need testing and adjusting the ebuilds to. |
| 22 |
> |
| 23 |
> Would it help at all to not always support different _rc's and .9999s? |
| 24 |
> Or would that just bite "us" (as in Gentoo) back with a delay? |
| 25 |
|
| 26 |
RCs are our chance to get upstream fixes into the release. If we skip |
| 27 |
them, it means we'll end up having to backport everything ourselves. |
| 28 |
It's a loss for us, and it's a loss for other people using LLVM. |
| 29 |
|
| 30 |
Plus, filing bugs as "release blockers" has a certain psychological |
| 31 |
effect. |
| 32 |
|
| 33 |
> |
| 34 |
> > |
| 35 |
> > 6. Work on setting up and configuring a buildbot for Gentoo LLVM builds. |
| 36 |
> > This is some effort and I don't have the time to learn how to do that. |
| 37 |
> > You'll probably need to set up a local instance and figure out how to |
| 38 |
> > set our builds before submitting anything upstream; in my experience |
| 39 |
> > they aren't very responsive to buildbot changes, so ideally we need to |
| 40 |
> > flesh out any problems early. |
| 41 |
> |
| 42 |
> GSOC-worthy project? |
| 43 |
|
| 44 |
Not sure. To rephrase what was once said to me, this is summer of |
| 45 |
*code*, not infra work. |
| 46 |
|
| 47 |
> |
| 48 |
> > |
| 49 |
> > Yes, that's a lot of work. I can't do it all myself, I'm already doing |
| 50 |
> > too much and this is having negative impact on my health. I really need |
| 51 |
> > help with this. |
| 52 |
> > |
| 53 |
> |
| 54 |
> I wonder if llvm and toolchain projects should join - not that there's |
| 55 |
> probably anyone in toolchain interested/capable of doing llvm/clang |
| 56 |
> currently. But they'd be the next with knowledge for at least simplest |
| 57 |
> version bumps if you lay back a bit. Remember this is just a hobby - |
| 58 |
> even though your work is very much appreciated, not worth of wearing |
| 59 |
> yourself out over. |
| 60 |
> |
| 61 |
> |
| 62 |
|
| 63 |
I don't think this will help in any way -- just like having more people |
| 64 |
on the project roster doesn't help. |
| 65 |
|
| 66 |
-- |
| 67 |
Best regards, |
| 68 |
Michał Górny |
Archives