On Tue, Feb 15, 2022 at 10:22 AM Alvaro Herrera <alvherre@alvh.no-ip.org> wrote:
> On 2022-Feb-15, Thomas Munro wrote:
> > My general plan for this stuff is to try to do just one back-patch for
> > each LLVM release, with all the changes in it, to reduce commit churn.
> > Hence commit messages that say "Track LLVM X ..." so that it's easy to
> > find all the changes for X around the time of X's release. In other
> > words I'll probably do the 14 back-patch next month, so our May
> > releases will compile and work against LLVM 14, due out in March.
>
> In this case, maybe you should get this task listed in RELEASE_CHANGES.
This really depends on *their* release cycle, not ours. Hmm. Well,
if we had a buildfarm animal that ran their latest release branch as
recently discussed, not their main branch, then we could say "if that
machine is failing, but seawasp is passing, now is the time to
back-patch all the 'Track LLVM X' patches; if seawasp is failing, we
should urgently look into why". I'm willing to set such an animal up,
but Fabien or Andres may want to... A bit of shell scripting to peek
at their branches or look for their RC1 tag or something like that
depending on what we decide is the right trigger point.
