How to Align GNOME Bug Reporting in Fedora with FESCo Policy

Introduction

For years, users filing bug reports against Fedora’s GNOME packages received an automatic reply stating that those reports were not actively monitored and should be submitted upstream instead. This practice, while convenient for maintainers, conflicted with the Fedora Engineering Steering Committee (FESCo) policy requiring maintainers to “deal with reported bugs in a timely manner.” In April 2023, FESCo discussed this disconnect and chose to refine the wording of the auto-reply. This guide walks you through the steps to bring your bug‑monitoring process into compliance with FESCo expectations, ensuring that every report receives proper attention while maintaining efficient workflows.

What You Need

• Fedora Packager Account – with maintainer privileges for GNOME packages.
• Access to the bug tracker (Red Hat Bugzilla for Fedora).
• Knowledge of FESCo policies – specifically the policy on bug handling (available at the FESCo documentation).
• Familiarity with GNOME GitLab – for upstream bug submission.
• Scripting or automation tools (e.g., Python, Fedora’s bugzilla tools) to adjust auto‑replies.
• Commitment to regular triage – allocate time weekly or bi‑weekly.

Step-by-Step Guide

Step 1: Review the Current FESCo Policy

Start by reading the official FESCo policy on bug handling. It mandates that package maintainers “deal with reported bugs in a timely manner.” This means each report requires an initial response, triage, and action (fix, close, or forward) within a reasonable timeframe. Take notes on specific requirements, such as response time windows and escalation paths. This understanding will guide your entire workflow.

Step 2: Audit Your Existing Auto‑Reply

Log into Bugzilla and examine the current auto‑reply template used for GNOME packages. Likely you will find a message that discourages filing bugs in Fedora and pushes users to the GNOME upstream tracker. Compare this wording against FESCo’s expectation. Note any phrases that downplay the importance of Fedora‑side monitoring, because those are the parts that need adjustment.

Step 3: Revise the Auto‑Reply Wording

Rewrite the automatic response to align with policy while keeping the process efficient. A good approach is to acknowledge receipt of the bug, commit to a review within a set period (e.g., 7 days), and then provide a clear path:

• If the issue is Fedora‑specific (e.g., packaging or integration), explain it will be handled within Fedora.
• If the issue is generic, request the user to also file an upstream report, but do not close the Fedora bug immediately – keep it open and link the upstream report.

Ensure the new message includes the maintainer’s name and a direct contact for escalation. Test the template in a staging environment before deploying.

Step 4: Set Up Regular Triage Schedules

Allocate a fixed time each week to review new bugs in your GNOME packages. Use Bugzilla’s saved searches to filter by component, status, and date. During triage:

• Read the report and any attached logs.
• Reproduce the issue if possible.
• Assign severity and priority consistent with Fedora guidelines.
• Respond with a meaningful update (not just an auto‑reply).

If you cannot fix immediately, set the bug status to ASSIGNED and add a comment about next steps. This demonstrates active monitoring to FESCo.

Step 5: Connect with GNOME Upstream

Establish a workflow to forward relevant bugs to the GNOME GitLab. Create a Bugzilla component that automates the forwarding process, or use a script that posts a brief summary and links from the Fedora bug to the upstream ticket. Update the Fedora bug status to UPSTREAM if that field exists, or add a keyword like ForwardedUpstream. This satisfies both the policy of dealing with bugs and the practical need to leverage upstream fixes.

Step 6: Communicate Changes to the Community

Post an announcement on the Fedora devel or GNOME mailing list explaining the revised auto‑reply and the new triage process. Encourage users to continue reporting in Fedora even if they also submit upstream. Emphasize that reports are now actively monitored. This builds trust and reduces duplicate submissions.

Step 7: Monitor and Adjust

After implementing changes, keep an eye on metrics: response time, bug closure rate, and user feedback. Use Bugzilla’s reporting features. If you notice a bottleneck, adjust the triage schedule or the auto‑reply template. FESCo may issue further guidance, so stay engaged with their discussions (e.g., the April 28 meeting outcomes). Periodically review the policy itself for updates.

Tips for Success

• Start small: Pilot the new process on one or two high‑impact packages before rolling out to all your GNOME packages.
• Use automation wisely: Scripts can handle repetitive tasks, but always include a human‑readable summary in the auto‑reply.
• Keep the auto‑reply concise: Users often skim; put the most important actions (e.g., “We will respond within 7 days”) at the top.
• Document your workflow: Create a wiki page for other maintainers of GNOME packages in Fedora. Share templates and triage tips.
• Don’t ignore upstream: Some bugs are better fixed upstream. Make sure your process doesn’t create a silo.
• Be transparent: If a bug cannot be fixed soon, say so. Informing users reduces frustration.
• Review FESCo minutes: They often contain nuance about expectations beyond the written policy.

By following these steps, you can turn a conflicting practice into a smooth, policy‑compliant process that serves both Fedora users and GNOME upstream. The key is to maintain active monitoring while using automation to preserve your limited time.