Split implementation tasks

[y1yang0]

Within PR #30 , a global implementation framework has been established, with the following functions remaining to be implemented:

• Setup Phase
  • isSetup - Check if setup phase is already done(because we can either otel setup + otel go build or just otel go build)
  • findDeps - Find all dependencies of the project being build @y1yang0
  • matchDeps - Match the hook code with these dependencies @y1yang0
  • addDeps - Introduce additional hook code by generating otel.instrumentation.go
  • refreshDeps - Run go mod tidy to refresh dependencies
  • store - Write the matched hook rules to match.txt
• Instrument Phase
  • load - Load matched hook rules from match.txt
  • match - Check if the current package should be instrumented
  • instrument - Instrument the target function

Please feel free to claim the implementation tasks.

[y1yang0]

I would like to claim Phase2 task

[kakkoyun]

@y1yang0 Let's talk about this in the next SIG meeting.
We should also utilize the projects as we talked.

[123liuziming]

I think we should spilt a more detailed task list so we can do that concurrently

[RomainMuller]

My speciality is more towards instrumentation / AST manipulation, so I'm definitely up to contribute on this.

[y1yang0]

Let me break it down into smaller tasks, so we can claim-implement-review more quickly

[pdelewski]

Two clear candidates for parallelization are:

• Dependency setup
• Instrumentation / AST manipulation

We can try to split this work further.

[kakkoyun]

Let's use Go Compile-Time Instrumentation - v0 (view) after creating the tasks as we discussed before.

[y1yang0]

@RomainMuller @kakkoyun @123liuziming @pdelewski and all community contributor

I've updated the implementation tasks based on PR #30. Please feel free to claim any tasks of interest and leave a comment to notify us.

I'm unsure whether the current granularity level works for you all. If a more granular task breakdown is needed, please let me know. Thank you!

[y1yang0]

For example, I will attempt to take ownership of findDeps and start implementing

[pdelewski]

@RomainMuller @kakkoyun @y1yang0 @123liuziming

I've been thinking about the list of tasks recently. It's great that we now have a basic framework with a well-defined workflow and clear entry points for the specific functionalities we need to implement.

Rather than treating these functions in isolation, we should approach them in terms of milestones—for example:
– instrumenting "hello world"
– instrumenting a basic HTTP server

This aligns with the idea of feature-based programming, where we focus on delivering vertical slices of functionality that are useful and testable from a user’s perspective.

In that sense, we don’t need to fully implement every individual function upfront. Instead, we should aim to implement only what’s necessary to satisfy each milestone or feature.

For example, we’ll likely need to more or less fully implement addDeps and refreshDeps. But functions like matchDeps (in the Setup phase) and load, match, and instrument (in the Instrumenting phase) may only require minimal implementation at this stage—just enough to support the current milestone.

Let me know your thoughts.

[ralf0131]

I think this is a good idea, which gives us a clear objective targeting end users.

@RomainMuller @kakkoyun @y1yang0 @123liuziming

I've been thinking about the list of tasks recently. It's great that we now have a basic framework with a well-defined workflow and clear entry points for the specific functionalities we need to implement.

Rather than treating these functions in isolation, we should approach them in terms of milestones—for example: – instrumenting "hello world" – instrumenting a basic HTTP server

This aligns with the idea of feature-based programming, where we focus on delivering vertical slices of functionality that are useful and testable from a user’s perspective.

In that sense, we don’t need to fully implement every individual function upfront. Instead, we should aim to implement only what’s necessary to satisfy each milestone or feature.

For example, we’ll likely need to more or less fully implement addDeps and refreshDeps. But functions like matchDeps (in the Setup phase) and load, match, and instrument (in the Instrumenting phase) may only require minimal implementation at this stage—just enough to support the current milestone.

Let me know your thoughts.

[y1yang0]

For example, we’ll likely need to more or less fully implement addDeps and refreshDeps. But functions like matchDeps (in the Setup phase) and load, match, and instrument (in the Instrumenting phase) may only require minimal implementation at this stage—just enough to support the current milestone.

I see. For the first milestone, our goal can be to instrument 'hello world', and during the implementation, we don't need to consider a broad set of corner cases.

[y1yang0]

I'll consider claiming the matchDeps task. Thanks!