commops/interns
16
8
Fork 4
Code Issues 8 Pull requests Projects 7 Activity

[Gonothi] Familiarize more with AI/ML SIG, and Packaging process #150

New issue
Closed
opened 2026-05-27 00:39:32 +00:00 by cybette · 15 comments
cybette commented 2026-05-27 00:39:32 +00:00
Owner
Copy link

Summary

Get better acquainted with teams and processes that will help with the internship project

Background

A few more onboarding tasks that's targetted for the specific internship project. You can start on it in Sprint 7 but since there are several parts and dependencies, I'll put it in the Sprint 8 milestone and adjust due date accordlingly.

"Learn more" in the deliverables below means getting acquainted with more knowledge/contacts to help your Outreachy project, you don't need to get 100% involved. Reading through the linked pages will suffice as completing the "learn more" tasks. If there are specific actions needed (e.g. reaching out to certain people and joining certain meetings), they will be indicated as separate items below.

Deliverables

Outcome

Success!

### Summary Get better acquainted with teams and processes that will help with the internship project ### Background A few more onboarding tasks that's targetted for the specific internship project. You can start on it in Sprint 7 but since there are several parts and dependencies, I'll put it in the Sprint 8 milestone and adjust due date accordlingly. "Learn more" in the deliverables below means getting acquainted with more knowledge/contacts to help your Outreachy project, you don't need to get 100% involved. Reading through the linked pages will suffice as completing the "learn more" tasks. If there are specific actions needed (e.g. reaching out to certain people and joining certain meetings), they will be indicated as separate items below. ### Deliverables - [x] Learn more about the AI/ML SIG https://fedoraproject.org/wiki/SIGs/AI-ML - [x] Join the Matrix room #ai-ml:fedoraproject.org - [x] Set up time to meet with Tim Flink (`@tflink:fedora.im` on matrix) - [x] Start attending the fortnightly [SIG meetings](https://fedoraproject.org/wiki/SIGs/AI-ML#Meetings) if the timing works for you, otherwise follow [ai-ml-sig on Discussion](https://discussion.fedoraproject.org/tag/ai-ml-sig/305) for meeting minutes - [x] Learn more about the Packaging Committee https://forge.fedoraproject.org/packaging/guidelines - [x] Check out Fedora Packaging Guidelines https://docs.fedoraproject.org/en-US/packaging-guidelines/ (<- this is the official one, the [one you used in the outreachy application phase](https://github.com/gtfrans2re/Fedora-RamaLama-RAG-Om26/blob/main/README.md?plain=1#L272) was someone's fork from 2019) - [x] fedora-review tool for package review https://pagure.io/FedoraReview - [x] Ask Justin, Tim, and other packagers what sources to consider (i.e. where those 30 years of knowledge/content are distilled) - [x] For example this RPM packaging guide https://rpm-packaging-guide.github.io/ (not Fedora specific, last updated 3 years ago) is it still relevant? - [x] Get examples of compliant and non-compliant spec files - [x] should output be similar to [fedora-review template](https://pagure.io/FedoraReview/blob/master/f/review_template.txt) (super detailed), or summary with issues? actionable (agentic)? ### Outcome Success!
👀 1
cybette changed title from [WIP] Familiarize more with AI/ML SIG, and Packaging process to [Gonothi] Familiarize more with AI/ML SIG, and Packaging process 2026-05-28 11:28:18 +00:00
gtfrans2re commented 2026-06-08 15:31:36 +00:00
Collaborator
Copy link

Hello, @cybette! What's Tim Flink's Matrix username, please?
I see two names on the Matrix channel when I search for the FP nick 'tflink'.

Hello, @cybette! What's Tim Flink's Matrix username, please? I see two names on the Matrix channel when I search for the FP nick 'tflink'.
cybette commented 2026-06-09 11:50:49 +00:00
Author
Owner
Copy link

@gtfrans2re Tim Flink is @tflink:fedora.im

@gtfrans2re Tim Flink is `@tflink:fedora.im`
❤️ 1
cybette added the due date 2026-07-06 2026-06-09 12:10:10 +00:00
gtfrans2re commented 2026-06-11 08:36:24 +00:00
Collaborator
Copy link

Thanks for Tim's Matrix username, @cybette. I have reached out to @tflink:fedora.im on Matrix and am waiting for a response.

Thanks for Tim's Matrix username, @cybette. I have reached out to @tflink:fedora.im on Matrix and am waiting for a response.
👍 1
gtfrans2re commented 2026-06-18 17:32:18 +00:00
Collaborator
Copy link

Hello, @cybette! I have completed the first four deliverables:

  • Learned about the AI/ML SIG — read through the SIG wiki.
  • Joined the Matrix room #ai-ml:fedoraproject.org.
  • Set up time to meet and virtually met with Tim Flink (@tflink:fedora.im on Matrix).
  • Started attending the fortnightly SIG meetings today itself (and following ai-ml-sig on Discussion for the minutes when the timing doesn't work).

I'm now getting more acquainted with the SIG and its members. The remaining deliverables (Packaging Committee, Fedora Packaging Guidelines, fedora-review, etc.) are the packaging-process side; I'll work through those next, ahead of the July 6 due date.

Hello, @cybette! I have completed the first four deliverables: - **Learned about the AI/ML SIG** — read through the [SIG wiki](https://fedoraproject.org/wiki/SIGs/AI-ML). - **Joined the Matrix room** `#ai-ml:fedoraproject.org`. - **Set up time to meet and virtually met with Tim Flink** (`@tflink:fedora.im` on Matrix). - **Started attending the fortnightly SIG meetings today itself** (and following ai-ml-sig on Discussion for the minutes when the timing doesn't work). I'm now getting more acquainted with the SIG and its members. The remaining deliverables (Packaging Committee, Fedora Packaging Guidelines, fedora-review, etc.) are the packaging-process side; I'll work through those next, ahead of the July 6 due date.
gtfrans2re commented 2026-06-23 10:33:53 +00:00
Collaborator
Copy link

The Fedora Packaging Committee is the body that determines the packaging guidelines for Fedora. It also approves exemptions to the guidelines and to the package review process where needed. Importantly, the FPC is an independent subcommittee of the Fedora Engineering Steering Committee (FESCo), so the FPC sets guidelines, with FESCo ratification as an optional step for certain changes.

A few things I picked up that are directly relevant to our project (since the guidelines are the corpus we'll eventually build the RPM RAG tool on):

  • How guidelines change: there's a defined six-step procedure — draft → committee review → committee vote → optional FESCo ratification → writeup → announcement. Drafts start as a fork/PR against the packaging-committee repo. This matters for us because it tells us how the guidelines evolve, which informs when our RAG corpus would need rebuilding (echoing the rebuild-trigger discussion from #149 or #154).
  • Meetings: the FPC meets weekly on Thursdays at 17:00 UTC (16:00 during US DST) on Matrix in #meeting-1:fedoraproject.org, with the agenda posted to the packaging mailing list beforehand and minutes kept in Meetbot.
  • Membership is a small group of experienced packagers (the FAS group is packaging-committee).

I'll start attending the FPC meetings on Matrix and keep an eye on the Fedora Calendar so I can sit in, follow the agenda/minutes, and get more familiar with the committee and how they work, which should give me a good grounding for the RPM packaging guidelines project.

Assisted-by: Claude Opus 4.8

The [Fedora Packaging Committee](https://fedoraproject.org/wiki/Packaging_Committee) is the body that **determines the packaging guidelines** for Fedora. It also approves exemptions to the guidelines and to the package review process where needed. Importantly, the FPC is an **independent subcommittee of the [Fedora Engineering Steering Committee (FESCo)](https://fedoraproject.org/wiki/Fedora_Engineering_Steering_Committee)**, so the FPC sets guidelines, with FESCo ratification as an optional step for certain changes. A few things I picked up that are directly relevant to our project (since the guidelines are the corpus we'll eventually build the RPM RAG tool on): - **How guidelines change:** there's a defined six-step procedure — draft → committee review → committee vote → optional FESCo ratification → writeup → announcement. Drafts start as a fork/PR against the [packaging-committee](https://pagure.io/packaging-committee/) repo. This matters for us because it tells us *how* the guidelines evolve, which informs when our RAG corpus would need rebuilding (echoing the rebuild-trigger discussion from #149 or #154). - **Meetings:** the FPC meets **weekly on Thursdays at 17:00 UTC** (16:00 during US DST) on Matrix in `#meeting-1:fedoraproject.org`, with the agenda posted to the `packaging` mailing list beforehand and minutes kept in Meetbot. - **Membership** is a small group of experienced packagers (the FAS group is `packaging-committee`). I'll start attending the FPC meetings on Matrix and keep an eye on the [Fedora Calendar](https://apps.fedoraproject.org/calendar/packaging/) so I can sit in, follow the agenda/minutes, and get more familiar with the committee and how they work, which should give me a good grounding for the RPM packaging guidelines project. <sub>_Assisted-by: Claude Opus 4.8_</sub>
gtfrans2re commented 2026-06-23 10:37:38 +00:00
Collaborator
Copy link

The Fedora Packaging Guidelines are the official, canonical rules for packaging software as RPMs in Fedora. (Note: the version I used during the Outreachy application phase was a 2019 fork; this docs.fedoraproject.org one is the current official source, which is an important correction for our corpus.)

What do they cover? a large, structured collection spanning:

  • Naming (Package Naming Guidelines) and Versioning (Version/Release fields, changelogs)
  • Licensing (must be a Fedora-approved license; the License: field must match the actual license)
  • Sources (Source: tags, matching upstream via checksums)
  • Dependencies (BuildRequires, automatic vs. manual, versioned deps)
  • Spec file requirements (American English, legibility, consistent macro use, %files, -devel/-doc/-static subpackages)
  • Many language/domain-specific guidelines (C/C++, Java, Python, D, etc.)

Key nuance for our tool — the guidelines use deliberate normative language:

  • "must" / "is required to" / "needs to" → deviation requires FPC approval.
  • "should" / "is suggested" → deviation is allowed, but the reasoning must be documented in the spec file.

This "MUST vs SHOULD" distinction is exactly the kind of thing our RAG tool would need to surface when checking a spec; a packager mostly needs to know which rule is a hard blocker versus a recommendation. Packages must also conform to the separate Review Guidelines, which is the checklist reviewers actually apply.

This is the body of knowledge (the "30 years" of packaging content) the main RPM project builds on, so getting familiar with its structure and that MUST/SHOULD framing is foundational.

Assisted-by: Claude Opus 4.8

The [Fedora Packaging Guidelines](https://docs.fedoraproject.org/en-US/packaging-guidelines/) are the official, canonical rules for packaging software as RPMs in Fedora. (Note: the version I used during the Outreachy application phase was a 2019 fork; this docs.fedoraproject.org one is the current official source, which is an important correction for our corpus.) **What do they cover**? a large, structured collection spanning: - **Naming** (Package Naming Guidelines) and **Versioning** (Version/Release fields, changelogs) - **Licensing** (must be a Fedora-approved license; the `License:` field must match the actual license) - **Sources** (`Source:` tags, matching upstream via checksums) - **Dependencies** (`BuildRequires`, automatic vs. manual, versioned deps) - **Spec file requirements** (American English, legibility, consistent macro use, `%files`, `-devel`/`-doc`/`-static` subpackages) - Many **language/domain-specific** guidelines (C/C++, Java, Python, D, etc.) **Key nuance for our tool** — the guidelines use deliberate normative language: - **"must" / "is required to" / "needs to"** → deviation requires FPC approval. - **"should" / "is suggested"** → deviation is allowed, but the reasoning must be documented in the spec file. This "MUST vs SHOULD" distinction is exactly the kind of thing our RAG tool would need to surface when checking a spec; a packager mostly needs to know *which* rule is a hard blocker versus a recommendation. Packages must also conform to the separate **[Review Guidelines](https://docs.fedoraproject.org/en-US/packaging-guidelines/ReviewGuidelines/)**, which is the checklist reviewers actually apply. This is the body of knowledge (the "30 years" of packaging content) the main RPM project builds on, so getting familiar with its structure and that MUST/SHOULD framing is foundational. <sub>_Assisted-by: Claude Opus 4.8_</sub>
👍 1
gtfrans2re commented 2026-06-23 10:41:08 +00:00
Collaborator
Copy link

fedora-review (package: fedora-review, originally by Tim Lauridsen) automates much of the "grunt work" of reviewing an RPM package for inclusion in Fedora. Given a package review request, it:

  • Downloads the SRPM & spec (e.g., from a Bugzilla review ticket),
  • Downloads the upstream source and checks md5/checksums,
  • Builds and installs the package in mock (or Koji, via --prebuilt),
  • Runs rpmlint,
  • Runs a battery of guideline checks, and
  • Generates a review template combining automated results with manual check items, which is the starting point that a human reviewer then completes.

It's plugin-based (checks for C/C++, Python, Java, R, Perl, Ruby, …) and extensible via a simple bash API. It's explicitly not a replacement for a human reviewer; it automates the mechanical checks and produces a structured template, leaving judgment calls to people.

Why it's highly relevant to our project:

  • The fedora-review template is essentially the output format our RPM tool might emulate. For instance, @cybette's question in #150 ("should output be similar to the fedora-review template, or a summary with issues?") points right at this.
  • It already encodes many Packaging/Review Guidelines as automated checks — useful prior art for understanding what's mechanically checkable vs. what needs guideline knowledge (where a RAG approach adds value).
  • There's active movement here too: the fedora-review-service runs it as CI, and a GSoC 2025 project is bringing fedora-review into Forgejo pull-request workflows, worth tracking since our work is also moving onto the Forge.

I'll experiment with running it against a sample package to see the template output firsthand and then share my findings here.

Assisted-by: Claude Opus 4.8

[fedora-review](https://github.com/timlau/FedoraReview) (package: `fedora-review`, originally by Tim Lauridsen) automates much of the "grunt work" of reviewing an RPM package for inclusion in Fedora. Given a package review request, it: - Downloads the **SRPM & spec** (e.g., from a Bugzilla review ticket), - Downloads the **upstream source** and checks md5/checksums, - **Builds and installs** the package in **mock** (or Koji, via `--prebuilt`), - Runs **rpmlint**, - Runs a battery of **guideline checks**, and - Generates a **review template** combining automated results with manual check items, which is the starting point that a human reviewer then completes. It's plugin-based (checks for C/C++, Python, Java, R, Perl, Ruby, …) and extensible via a simple bash API. It's explicitly **not a replacement for a human reviewer**; it automates the mechanical checks and produces a structured template, leaving judgment calls to people. **Why it's highly relevant to our project:** - The **fedora-review template** is essentially the output format our RPM tool might emulate. For instance, @cybette's question in #150 ("should output be similar to the fedora-review template, or a summary with issues?") points right at this. - It already encodes many Packaging/Review Guidelines as automated checks — useful prior art for understanding what's mechanically checkable vs. what needs guideline *knowledge* (where a RAG approach adds value). - There's active movement here too: the [fedora-review-service](https://github.com/FrostyX/fedora-review-service) runs it as CI, and a [GSoC 2025 project](https://communityblog.fedoraproject.org/gsoc-2025-bringing-package-reviews-to-forgejo/) is bringing fedora-review into Forgejo pull-request workflows, worth tracking since our work is also moving onto the Forge. I'll experiment with running it against a sample package to see the template output firsthand and then share my findings here. <sub>_Assisted-by: Claude Opus 4.8_</sub>
cybette commented 2026-06-23 11:30:59 +00:00
Author
Owner
Copy link

@gtfrans2re wrote in #150 (comment):

fedora-review (package: fedora-review, originally by Tim Lauridsen)

That's the original tool, note that it was last updated 10 years ago. Please refer to the current tooling: https://pagure.io/FedoraReview which I mentioned in the issue, and recently migrated to Forgejo: https://forge.fedoraproject.org/packaging/FedoraReview

@gtfrans2re wrote in https://forge.fedoraproject.org/commops/interns/issues/150#issuecomment-826233: > [fedora-review](https://github.com/timlau/FedoraReview) (package: `fedora-review`, originally by Tim Lauridsen) That's the original tool, note that it was last updated 10 years ago. Please refer to the current tooling: https://pagure.io/FedoraReview which I mentioned in the issue, and recently migrated to Forgejo: https://forge.fedoraproject.org/packaging/FedoraReview
gtfrans2re commented 2026-06-23 16:35:42 +00:00
Collaborator
Copy link

Thanks for the correction, @cybette! Noted with thanks. I'll refer to the current tooling at pagure.io/FedoraReview (now migrated to the Forge at forge.fedoraproject.org/packaging/FedoraReview) rather than the original timlau repo. Good to know the maintained version is already on the Forge too; I'll use that as the reference going forward.

Thanks for the correction, @cybette! Noted with thanks. I'll refer to the current tooling at [pagure.io/FedoraReview](https://pagure.io/FedoraReview) (now migrated to the Forge at [forge.fedoraproject.org/packaging/FedoraReview](https://forge.fedoraproject.org/packaging/FedoraReview)) rather than the original timlau repo. Good to know the maintained version is already on the Forge too; I'll use that as the reference going forward.
👍 1
gtfrans2re commented 2026-06-24 06:22:03 +00:00
Collaborator
Copy link

I looked into the RPM Packaging Guide (source repo, originally by Adam Miller).

What it is: a general, tutorial-style introduction to RPM packaging that explains the fundamentals (NVR naming, spec file anatomy: %prep/%build/%install/%files/%changelog, building with rpmbuild, quality-checking with rpmlint, working with macros). It's written in AsciiDoc, publishes HTML + PDF via GitHub Actions, and notably maintains separate community (upstream) and RHEL (downstream) index pages.

Is it still relevant? Partly, at least to me, and here is my take:

  • Good for fundamentals/onboarding: the core mechanics of how RPMs and spec files work don't change quickly, so it's solid background material and a gentle on-ramp.
  • Not Fedora-specific and showing its age: as flagged by @cybette, it hasn't been updated in approx 3 years, and it's a general RPM guide, not the Fedora rules. It won't reflect current Fedora-specific policy (e.g., SPDX license identifiers, current naming/licensing guidelines, FPC decisions).

Recommendation for the corpus: treat it as secondary/contextual rather than authoritative. The authoritative sources for our RAG tool should be the official Fedora Packaging Guidelines and Review Guidelines. This guide could optionally supplement them for "what is a spec file / how does rpmbuild work" background, but we'd want to be careful it doesn't introduce outdated or non-Fedora guidance, so probably best excluded from the authoritative corpus, or clearly weighted below the official docs if included.

Assisted-by: Claude Opus 4.8

I looked into the [RPM Packaging Guide](https://rpm-packaging-guide.github.io/) ([source repo](https://github.com/redhat-developer/rpm-packaging-guide), originally by Adam Miller). **What it is:** a general, tutorial-style introduction to RPM packaging that explains the fundamentals (NVR naming, spec file anatomy: `%prep`/`%build`/`%install`/`%files`/`%changelog`, building with `rpmbuild`, quality-checking with `rpmlint`, working with macros). It's written in AsciiDoc, publishes HTML + PDF via GitHub Actions, and notably maintains separate **community (upstream)** and **RHEL (downstream)** index pages. **Is it still relevant?** Partly, at least to me, and here is my take: - **Good for fundamentals/onboarding**: the core mechanics of how RPMs and spec files work don't change quickly, so it's solid background material and a gentle on-ramp. - **Not Fedora-specific and showing its age**: as flagged by @cybette, it hasn't been updated in approx 3 years, and it's a *general* RPM guide, not the Fedora rules. It won't reflect current Fedora-specific policy (e.g., SPDX license identifiers, current naming/licensing guidelines, FPC decisions). **Recommendation for the corpus:** treat it as **secondary/contextual** rather than authoritative. The authoritative sources for our RAG tool should be the official [Fedora Packaging Guidelines](https://docs.fedoraproject.org/en-US/packaging-guidelines/) and [Review Guidelines](https://docs.fedoraproject.org/en-US/packaging-guidelines/ReviewGuidelines/). This guide could optionally supplement them for "what is a spec file / how does rpmbuild work" background, but we'd want to be careful it doesn't introduce outdated or non-Fedora guidance, so probably best excluded from the authoritative corpus, or clearly weighted below the official docs if included. <sub>_Assisted-by: Claude Opus 4.8_</sub>
gtfrans2re commented 2026-06-24 06:24:50 +00:00
Collaborator
Copy link

For training or evaluating the RPM tool, we'll want a set of compliant and non-compliant spec files. Here's where I think we can source them:

Compliant examples:

  • Existing Fedora packages: every package already in Fedora has passed review, so their spec files (browsable via src.fedoraproject.org / dist-git) are a large pool of real, compliant examples.
  • The simple worked examples in the RPM Packaging Guide and the Fedora Packaging Guidelines themselves (e.g., the hello/bello-style specs) are clean, minimal references.

Non-compliant examples:

  • Past package review tickets (Bugzilla, and now the Forgejo review workflow) are the richest source as they capture real spec files before fixes, with reviewers pointing out exactly which guideline was violated and how it was resolved. That before/after is gold for a tool meant to flag issues.
  • rpmlint output on intentionally-broken specs gives concrete, labeled violations.
  • We can also synthesize non-compliant variants by taking a compliant spec and injecting known violations (wrong License: field, missing %license, hardcoded paths, un-versioned deps, non-American-English, etc.); this mirrors the "adversarial test set" idea from the PyData talk in #154.

Open question for the packagers (tied to the "ask Justin/Tim" item): is there an existing curated set of good/bad examples they use for training new reviewers, or should we assemble our own from dist-git (compliant) + review tickets (non-compliant)? I'll fold this into the outreach.

This pairs naturally with the eval work in #154; these examples become the test cases for measuring whether the tool correctly identifies compliance issues.

Assisted-by: Claude Opus 4.8

For training or evaluating the RPM tool, we'll want a set of **compliant** and **non-compliant** spec files. Here's where I think we can source them: **Compliant examples:** - **Existing Fedora packages**: every package already in Fedora has passed review, so their spec files (browsable via [src.fedoraproject.org](https://src.fedoraproject.org/) / dist-git) are a large pool of real, compliant examples. - The simple worked examples in the RPM Packaging Guide and the Fedora Packaging Guidelines themselves (e.g., the `hello`/`bello`-style specs) are clean, minimal references. **Non-compliant examples:** - **Past package review tickets** (Bugzilla, and now the Forgejo review workflow) are the richest source as they capture real spec files *before* fixes, with reviewers pointing out exactly which guideline was violated and how it was resolved. That before/after is gold for a tool meant to flag issues. - **rpmlint** output on intentionally-broken specs gives concrete, labeled violations. - We can also **synthesize** non-compliant variants by taking a compliant spec and injecting known violations (wrong `License:` field, missing `%license`, hardcoded paths, un-versioned deps, non-American-English, etc.); this mirrors the "adversarial test set" idea from the PyData talk in #154. **Open question for the packagers** (tied to the "ask Justin/Tim" item): is there an existing **curated** set of good/bad examples they use for training new reviewers, or should we assemble our own from dist-git (compliant) + review tickets (non-compliant)? I'll fold this into the outreach. This pairs naturally with the eval work in #154; these examples become the test cases for measuring whether the tool correctly identifies compliance issues. <sub>_Assisted-by: Claude Opus 4.8_</sub>
👍 1
gtfrans2re commented 2026-06-25 17:22:21 +00:00
Collaborator
Copy link

Hello, @cybette! About the output type, this is really a product design question for the tool, and I think the answer depends on the audience. Laying out the trade-offs:

Option A: fedora-review-template style (super detailed):

  • Mirrors the familiar fedora-review output: a full check-by-check template (MUST/SHOULD items, each marked pass/fail/NA), plus build/rpmlint results.
  • Pro: comprehensive, matches what reviewers already expect, nothing gets missed, easy to cross-reference against the guidelines.
  • Con: verbose; a newcomer may struggle to know what to do first; much of it duplicates what fedora-review already automates.

Option B — summary of issues (actionable / agentic):

  • A concise, prioritized list: "here are the N problems, here's the guideline each violates, here's the suggested fix," ideally ordered blockers-first (MUST), then recommendations (SHOULD).
  • Pro: actionable, newcomer-friendly, plays to the LLM/RAG strength (explaining why and how to fix, grounded in the guideline text) rather than re-implementing mechanical checks.
  • Con: risks omitting things if the summarization is too aggressive; needs to stay grounded to avoid hallucinated "fixes."

My lean: the tool adds the most new value as Option B, because the mechanical pass/fail checking is already well covered by fedora-review/rpmlint. Where a RAG approach shines is in turning "this fails check X" into "here's the relevant guideline, here's why your spec violates it, and here's how to fix it", for instance, the explanatory, actionable layer on top.

A possible best-of-both: lead with a prioritized issue summary (B), with an option to expand into the full detailed template (A) for reviewers who want the complete checklist. That keeps it newcomer-friendly without losing comprehensiveness.

Happy to align with mentors on which direction to prioritize first, as discussed today via Matrix voice notes with @jflory7; this also connects to @cybette's note on the fedora-review template format in the deliverables.

Assisted-by: Claude Opus 4.8

Hello, @cybette! About the output type, this is really a **product design** question for the tool, and I think the answer depends on the audience. Laying out the trade-offs: **Option A: fedora-review-template style (super detailed):** - Mirrors the familiar [fedora-review](https://pagure.io/FedoraReview) output: a full check-by-check template (MUST/SHOULD items, each marked pass/fail/NA), plus build/rpmlint results. - Pro: comprehensive, matches what reviewers already expect, nothing gets missed, easy to cross-reference against the guidelines. - Con: verbose; a newcomer may struggle to know *what to do first*; much of it duplicates what fedora-review already automates. **Option B — summary of issues (actionable / agentic):** - A concise, prioritized list: "here are the N problems, here's the guideline each violates, here's the suggested fix," ideally ordered blockers-first (MUST), then recommendations (SHOULD). - Pro: actionable, newcomer-friendly, plays to the LLM/RAG strength (explaining *why* and *how to fix*, grounded in the guideline text) rather than re-implementing mechanical checks. - Con: risks omitting things if the summarization is too aggressive; needs to stay grounded to avoid hallucinated "fixes." **My lean:** the tool adds the most *new* value as **Option B**, because the mechanical pass/fail checking is already well covered by fedora-review/rpmlint. Where a RAG approach shines is in turning "this fails check X" into "here's the relevant guideline, here's why your spec violates it, and here's how to fix it", for instance, the explanatory, actionable layer on top. A possible best-of-both: **lead with a prioritized issue summary (B), with an option to expand into the full detailed template (A)** for reviewers who want the complete checklist. That keeps it newcomer-friendly without losing comprehensiveness. Happy to align with mentors on which direction to prioritize first, as discussed today via Matrix voice notes with @jflory7; this also connects to @cybette's note on the fedora-review template format in the deliverables. <sub>_Assisted-by: Claude Opus 4.8_</sub>
gtfrans2re commented 2026-06-25 20:13:53 +00:00
Collaborator
Copy link

I discussed potential sources for the RPM packaging guidelines RAG corpus with Tim. He recommended considering Maximum RPM as an additional historical resource and suggested using package review bugs as a potential source of compliant vs. non-compliant spec file examples.

We also discussed output formats, with Tim favoring a concise summary of issues over generating a full fedora-review template. Additionally, he raised questions about ROCm and Radeon GPU support in the planned tooling stack, highlighting hardware compatibility as an area to validate.

Takeaway: Expand corpus research beyond official guidelines to include historical and review-related sources where practical, focus on actionable issue summaries as the primary output, and verify GPU/ROCm compatibility assumptions during implementation.

Assisted-by: Claude Opus 4.8

I discussed potential sources for the RPM packaging guidelines RAG corpus with Tim. He recommended considering Maximum RPM as an additional historical resource and suggested using package review bugs as a potential source of compliant vs. non-compliant spec file examples. We also discussed output formats, with Tim favoring a concise summary of issues over generating a full fedora-review template. Additionally, he raised questions about ROCm and Radeon GPU support in the planned tooling stack, highlighting hardware compatibility as an area to validate. **Takeaway:** Expand corpus research beyond official guidelines to include historical and review-related sources where practical, focus on actionable issue summaries as the primary output, and verify GPU/ROCm compatibility assumptions during implementation. <sub>_Assisted-by: Claude Opus 4.8_</sub>
jflory7 commented 2026-07-01 02:20:11 +00:00
Owner
Copy link

Closing: Onboarding phase complete

The exploration and onboarding work tracked here has served its purpose — @gtfrans2re is now familiar with the AI/ML SIG, packaging processes, and the tools relevant to the internship project. Closing this to shift focus to the core project deliverables (#159, #160, #161).

Assisted-by: Claude Opus 4.6 (1M context)

### Closing: Onboarding phase complete The exploration and onboarding work tracked here has served its purpose — @gtfrans2re is now familiar with the AI/ML SIG, packaging processes, and the tools relevant to the internship project. Closing this to shift focus to the core project deliverables (#159, #160, #161). <sub>_Assisted-by: Claude Opus 4.6 (1M context)_</sub>
👀 1
gtfrans2re commented 2026-07-01 10:39:59 +00:00
Collaborator
Copy link

Thanks for reviewing and closing this issue, @jflory7. I will use the insights I gained from this to improve my work on the main project.

Thanks for reviewing and closing this issue, @jflory7. I will use the insights I gained from this to improve my work on the main project.
Sign in to join this conversation.
No Branch/Tag specified
Branches Tags
main
No results found.
Labels
Clear labels   
state
ready for review
 Ready for final reviewer by a mentor. This label is used for tickets in the "In Progress" column on the Forgejo Projects Boards.

  
function
analytics
 Community Social Analytics. One of the two main functions of the Community Operations Team. All issues/tasks should identify a function as different team members are responsible for different function

  
function
communications
 Community Blog, newsletters, outreach content, Magazine coordination, and community messaging

  
function
docs
 Documentation site, playbooks, guides, knowledge base, and contributor reference materials

  
function
events
 Event production, release parties, conferences, streaming, video processing, and community event logistics

  
function
onboarding
 Newcomer experience, mentoring, intern programs, team growth, and contributor onboarding

  
function
operations
 Team governance, repo management, meeting logistics, infrastructure, and internal process

  
good first issue
Good tickets to begin with (if you want to get involved, try working on one of these!)

  
help wanted
Tickets where we need help or need feedback from the wider Fedora community

  
needs
changes
 Needs changes or fixes before closing

  
needs
reporter feedback
 Additional feedback or information from the reporter is needed to advance

  
needs
team vote
 A vote is required from Fedora Community Operations Team members in order to advance

  
needs
triage
 A repository maintainer is needed to triage this further

  
scope
bug
 Something isn't working

  
scope
improvement
 Requests for something we are either repeating or improving

  
scope
new
 Requests for a new task or project for the team

  
state
approved
 Tickets that received approval by the Fedora Community Operations Team

  
state
blocked
 Cannot move forward: blocked by feedback, other tickets, etc.

  
state
duplicate
 This issue or merge request already exists

  
state
invalid
 This doesn't seem right

  
state
wontfix
 This will not be worked on

No labels
state
ready for review
function
analytics
function
communications
function
docs
function
events
function
onboarding
function
operations
good first issue
help wanted
needs
changes
needs
reporter feedback
needs
team vote
needs
triage
scope
bug
scope
improvement
scope
new
state
approved
state
blocked
state
duplicate
state
invalid
state
wontfix
Milestone
Clear milestone
No items
Projects
Clear projects
No items
No project
2026 Intern Sprint Planning (Sprints 1–8)
Assignees
Clear assignees
No assignees
gtfrans2re
3 participants
Notifications
Due date
The due date is invalid or out of range. Please use the format "yyyy-mm-dd".

2026-07-06

Dependencies

No dependencies set.

Reference
commops/interns#150
No description provided.