Volunteer as maintainer

[nascentcore-eng]

To whom it may concern,

Background:

This repo seems no longer actively maintained.
#315
#314

This repo still have active uses. We at tricorder.dev are one of them.
One may issue is that this repo lags behind iovisor/bcc, which should be fairly straightforward to keep in sync

What we propose:

We (https://tricorder.dev is building eBPF+WASM-based Observability platform, not-yet publicly launched) are using gobpf.
We'll commit resources to keep gobpf in sync with upstream bcc
Additional responsibilities, like bug fixes and new features are confined to the scope of Tricorder's own needs
(I.e., we'll fix and upstream any issues affects Tricorder's use of gobpf, but have no resources beyond that)

Anticipated outcomes:

Gobpf will be useable for the foreseeable future.

Any suggestions?

[alban]

Hello, thanks for volunteering!

I am curious what are the requirements you had that made you select gobpf (instead of other Go libraries like cilium/ebpf or aquasecurity/libbpfgo): is it the ability to compile code just-in-time? Are there other features that you need in gobpf that are not implemented elsewhere?

I see you commented on #304 that you would like to see relevant parts of gobpf migrated to bcc as well. Do you want to participate in that effort? I guess in that case, there might be nothing left in gobpf to maintain.

[nascentcore-eng]

We use gobpf for the BCC go binding, and that in turn is because we have accumulated BCC style ebpf code and don't want to rewrite.

Minor reason is derisk development, as we are familiar with BCC, not as good with cilium and other libbpf style library. We are going to support libbpf etc. But time and manpower are limited.

As for participating migrating to BCC:
No, we don't have time or manpower for that. At this point we are only able to keep gobpf BCC binding in sync with BCC.

[AeroNotix]

So this went nowhere?

[mauriciovasquezbernal]

Please check #232 (comment) to see the current plan for the project.