Tracepoint project: draft timeline for feedback

Tracepoint project: draft timeline for feedback

[Temitope obabi]

Hi Steven and Julian,

As part of my Outreachy application, I need a project timeline for
removing unused tracepoints. Here is my draft, based on the patches I
have sent so far (assuming about 12 weeks):

Weeks 1-2: Set up the kernel build with tracing enabled. List candidate
tracepoints by checking which definitions have no callers. Choose the
first subsystems to work on, and ask you which ones you prefer.

Weeks 3-5: Send removal patches in small batches, one subsystem at a
time. For each one, check the callers and search lore for duplicates
first. Then build, run checkpatch, send to the maintainers from
get_maintainer, and Cc you and the Outreachy list.

Weeks 6-8: Handle review feedback and send v2 or v3 as needed. Keep a
list of what is sent, accepted or waiting, and follow up politely on
patches with no reply.

Weeks 9-10: Take on harder cases, such as tracepoints that look unused
but might be used by tools like trace-cmd or perf. Ask Steven before
removing anything unclear.

Weeks 11-12: Follow up on unmerged patches, update the status list, and
write the final report.

Do you think this is realistic? Is there anything you would add, remove
or change?

Thank you,
Temitope

Re: Tracepoint project: draft timeline for feedback

[Julia Lawall]

On Sun, 8 Nov 2026, Temitope obabi wrote:

> Hi Steven and Julian,
>
> As part of my Outreachy application, I need a project timeline for
> removing unused tracepoints. Here is my draft, based on the patches I
> have sent so far (assuming about 12 weeks):
>
> Weeks 1-2: Set up the kernel build with tracing enabled. List candidate
> tracepoints by checking which definitions have no callers. Choose the
> first subsystems to work on, and ask you which ones you prefer.
>
> Weeks 3-5: Send removal patches in small batches, one subsystem at a
> time. For each one, check the callers and search lore for duplicates
> first. Then build, run checkpatch, send to the maintainers from
> get_maintainer, and Cc you and the Outreachy list.
>
> Weeks 6-8: Handle review feedback and send v2 or v3 as needed. Keep a
> list of what is sent, accepted or waiting, and follow up politely on
> patches with no reply.
>
> Weeks 9-10: Take on harder cases, such as tracepoints that look unused
> but might be used by tools like trace-cmd or perf. Ask Steven before
> removing anything unclear.
>
> Weeks 11-12: Follow up on unmerged patches, update the status list, and
> write the final report.
>
> Do you think this is realistic? Is there anything you would add, remove
> or change?

A small detail is that after the application period is over, this list
goes quiet.  No need to send patches here.

julia

>
> Thank you,
> Temitope
>

Re: Tracepoint project: draft timeline for feedback

[Julian Braha]

[-- Attachment #1.1: Type: text/plain, Size: 1601 bytes --]

On 11/8/26 11:47, Temitope obabi wrote:
> Hi Steven and Julian,
> 
> As part of my Outreachy application, I need a project timeline for
> removing unused tracepoints. Here is my draft, based on the patches I
> have sent so far (assuming about 12 weeks):
> 
> Weeks 1-2: Set up the kernel build with tracing enabled. List candidate
> tracepoints by checking which definitions have no callers. Choose the
> first subsystems to work on, and ask you which ones you prefer.

I think you already have the kernel build setup with tracing enabled for
your existing patches, right?

Also, it may be better to rotate across the different subsystems.
Otherwise, it may overwhelm each maintainer to receive many patches
within one week.

> 
> Weeks 3-5: Send removal patches in small batches, one subsystem at a
> time. For each one, check the callers and search lore for duplicates
> first. Then build, run checkpatch, send to the maintainers from
> get_maintainer, and Cc you and the Outreachy list.
> 
> Weeks 6-8: Handle review feedback and send v2 or v3 as needed. Keep a
> list of what is sent, accepted or waiting, and follow up politely on
> patches with no reply.
> 
> Weeks 9-10: Take on harder cases, such as tracepoints that look unused
> but might be used by tools like trace-cmd or perf. Ask Steven before
> removing anything unclear.
> 
> Weeks 11-12: Follow up on unmerged patches, update the status list, and
> write the final report.
> 
> Do you think this is realistic? Is there anything you would add, remove
> or change?
> 
> Thank you,
> Temitope
> 

[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 236 bytes --]