20250724 mirror and lei fixes #20
Conversation
We'll be extending the configuration documentaiton so move it to its own file. Signed-off-by: Luis Chamberlain <[email protected]>
We always clone a full repository. This is counter productive and wasteful. Allow users to specify that they are using kpd to help test patches for a git tree which we should expect a mirror on a target mirror path. We simply check for a mirror for you git tree and if present we use it. So for example, all kdevops enterprise deployments can easily profit from this as kdevops has support to mirror all target git trees it supports under /mirror/ through an NFS export for clients. And so small thing guests can be used for kpd instances, which can leverage this NFS export. This allows kpd to be run on smaller guests with less storage needs. This should allow more than one kpd instance to run on small guests too. Generated-by: Claude AI Signed-off-by: Luis Chamberlain <[email protected]>
Give Claude Code some guidance on our expecations. Generated-by: Claude AI Signed-off-by: Luis Chamberlain <[email protected]>
I've asked Claude Code to just extend the documentation as best as possible. Here as some updates. Generated-by: Claude AI Signed-off-by: Luis Chamberlain <[email protected]>
Add a new command-line option that allows users to run KPD in dry-run mode to list candidate patches without processing them. This is useful for debugging issues with patch detection and understanding what patches KPD would process. The dry-run mode: - Fetches relevant subjects from Patchwork using the same logic as normal operation - Lists all candidate patches with their series information - Exits without creating PRs or making any changes - Provides clear output showing patch subjects, series IDs, and metadata This helps diagnose issues like patches being outside the lookback window or problems with the Patchwork API integration. Generated-by: Claude AI Signed-off-by: Luis Chamberlain <[email protected]>
Fix a critical bug in patch filtering where project ID comparison was failing due to type mismatch. The configuration file specifies project IDs as strings (e.g., "423"), but the Patchwork API returns them as integers (e.g., 423). This caused the comparison in _is_patch_matching() to fail, resulting in no patches being detected as matching. This bug was preventing KPD from detecting candidate patches in lei-based patchwork instances, including the Linux firmware loader project. The fix converts the expected_value to int before comparison for properties in PATCH_FILTERING_PROPERTIES (project, delegate). Tested with the firmware loader project - now successfully detects patches including "firmware_loader: prevent integer overflow in firmware_loading_timeout()". Since lei-based patchwork instances now work, updates docs to declare it as supported. Generated-by: Claude AI Signed-off-by: Luis Chamberlain <[email protected]>
To help developers embrace claude code give examples and gradings of what Claude Code did. We can update with commit IDS and URLs later. Generated-by: Claude AI Signed-off-by: Luis Chamberlain <[email protected]>
|
@mcgrof your efforts to make improvements to KPD are greatly appreciated. I also sympathize with your enthusiasm about employing LLMs to do some of the work. However let's also not make the review process unnecessarily difficult. And let's not transform KPD into a "LLM-first" project, because it's not. Instead of closing an re-opening a PR on each new iteration, update existing PR. Let's not put Let's not bloat documentation with LLM-written paragraphs. LLM tends to be verbose with little substance, when it comes to documentation. It looks nice, but in order to determine whether the text is actually useful, a reviewer (me in this case) has to read/edit all of it: which is time-consuming and wasteful. Updating documentation is great, but please be thoughtful about what you're updating and why. I hope my objections make sense, and I look forward to you updating and re-opening #16 |
Alright. Hopefully this is it.