Re: [PATCH dwarves v4 0/3] btf_encoder: refactor emission of BTF funcs

[Arnaldo Carvalho de Melo <acme@kernel.org>]

On Fri, Nov 14, 2025 at 03:40:36PM +0000, Alan Maguire wrote:
> On 14/11/2025 02:10, Arnaldo Carvalho de Melo wrote:
> > On Thu, Nov 13, 2025 at 09:20:44AM -0800, Alexei Starovoitov wrote:
> >> On Thu, Nov 13, 2025 at 8:37 AM Alan Maguire <alan.maguire@oracle.com> wrote:
> >>>
> >>> On 06/11/2025 01:28, Ihor Solodrai wrote:
> >>>> This series refactors a few functions that handle how BTF functions
> >>>> are emitted.
> >>>>
> >>>> v3->v4: Error handling nit from Eduard
> >>>> v2->v3: Add patch removing encoder from btf_encoder_func_state

> >>>> v3: https://lore.kernel.org/dwarves/20251105185926.296539-1-ihor.solodrai@linux.dev/
> >>>> v2: https://lore.kernel.org/dwarves/20251104233532.196287-1-ihor.solodrai@linux.dev/
> >>>> v1: https://lore.kernel.org/dwarves/20251029190249.3323752-2-ihor.solodrai@linux.dev/

> >>> series applied to the next branch of
> >>> https://git.kernel.org/pub/scm/devel/pahole/pahole.git/

> >> Same rant as before...
> >> Can we please keep it normal with all changes going to master ?
> >> This 'next' branch confused people in the past.
> > 
> > I think the problem before was that it sat there for far too long.
> > 
> > I see value in it staying there for a short period for some eventual
> > rebase and for some CI thing, to avoid polluting, think of it as some
> > topic branch on the way to master.

Somehow my reply via the smartphone didn't seem to have made to the
list...
 
> Yeah, I think if we can augment CI to cover more we can narrow this
> window, aiming for zero as the test coverage improves.

So the 'next' is an artifact for CI usage, i.e. if we just don't
announce that it was merged, do it for the CI sake and then when it runs
and don't detect any problem we go ahead and merge into master and
announce that it was merged, nothing of this drama would take place.

The best thing going forward I think is to have AI reviewing just like
with the BPF patches, having the patches, once posted to the list by the
contributors, trigger the CI, that amongst other things do the AI
reviewing, if all is ok, maintainers get some nudge that AI bot is ok,
etc and merge it in master, annouce publicly, yadda, yadda.

> The other thing we should think about maybe is syncing
> github.com/acmel/dwarves with pahole.git as many people are pulling
> from github.
> Should we discourage using the github repo, or just find a way to
> mirror pahole.git automatically? Thanks!

I think we should have a https://github.com/pahole/ area that is
administered by the pahole maintainer(s), just like there are:

https://git.kernel.org/pub/scm/linux/kernel/git/perf/perf-tools.git/
https://git.kernel.org/pub/scm/linux/kernel/git/perf/perf-tools-next.git/

For the project (current merge window, next merge window) and my
personal, previously canonical, perf and other kernel work repo:

https://git.kernel.org/pub/scm/linux/kernel/git/acme/linux.git/

:-)

- Arnaldo