Re: pgsql: Track LLVM 15 changes.
От | Thomas Munro |
---|---|
Тема | Re: pgsql: Track LLVM 15 changes. |
Дата | |
Msg-id | CA+hUKG+LX+mjBTPV=u4RnZU_5sp=BgCHh_91a1f1NFoKphtJWQ@mail.gmail.com обсуждение исходный текст |
Ответ на | Re: pgsql: Track LLVM 15 changes. (Alvaro Herrera <alvherre@alvh.no-ip.org>) |
Ответы |
Re: pgsql: Track LLVM 15 changes.
|
Список | pgsql-committers |
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.
В списке pgsql-committers по дате отправления: