Project:Bug-cleaners

From Gentoo Wiki
Jump to:navigation Jump to:search
Bug cleaners
Description The Gentoo Bug Cleaners project aims to clean up the oldest bugs in Bugzilla.
Project email maintainer-wanted@gentoo.org
IRC channel #gentoo-bugs (webchat)
Lead(s) none
Last elected: 2016-04-21
Member(s)
Subproject(s)
(and inherited member(s)) 		(none)
Parent Project Quality Assurance
Project listing

The goal of the Bug cleaners project is twofold:

  • The main purpose of the project is to close bugs on Bugzilla that do no longer apply due to versions and/or packages that are no longer present in the Portage tree.
  • As a side effect, it also tries to look for solutions for the oldest bugs.

For those that still have use, it attempts to inform the persons involved in the bug that the bug is still open if the bug is important; inviting them to make a decision on it.

Resources

Queries that can be handy for finding old bugs include:

First steps

Because one cannot just rush in and go hunt at random bugs and expect people to agree with one's actions; the very first steps we will take is to raise the necessary discussion to get feedback on what the community wants us to do exactly, which clarifies the further limits and scope of the project.

Questions to be answered

We will need to get some questions answered to proceed:

  • How old is "oldest"?
  • When is a bug considered still useful?
  • Are there other types of bugs we could or need to look into?
  • Can this effort replace the Bug Day that does not receive interest lately?
  • Do we need a mail alias so we can get CC-ed on bugs? (Effectively allowing users to help as well.)
  • Do we need a mail alias so we can get assigned on bugs? (*unsure*)
  • What to do in exceptional cases? (Cannot be answered until we identified them.)

This will be discussed on the mailing lists.

Bug summaries

Preferably, bugs requesting new packages should have similar formatting for the summary or title. This will allow for easy parsing of the maintainer-wanted bugs and quickly inform readers of the name and purpose of requested packages. Suggested guidelines for package requests are:

  • The summary should contain the package name, the category, and a brief description of the package.
    • Category suggestions are fine, but if unsure, just leave it out and mention in a comment.
    • If the category isn't known, then it can be omitted.
  • Version numbers should not be in the summary.
    • The request is for the atom to be added in general, versioning will be dependent on the maintainer and upstream availability.
  • If the addition of one package is dependent on the addition of another, this should be indicated with the Bugzilla Depends On field.
    • Depends On should only be set for the immediate dependency - in the example below, libbaz would is only used for bar, not foo.

Examples of good bug summaries include:

  • Bug 1234 - app-editors/foo: a multicoloured text editor
  • Bug 1236 - app-dicts/bar: a dictionary of bad words for app-editors/foo [depends on 1234]
  • Bug 1238 - libbaz: a library for accessing app-dicts/bar [depends on 1236]

Examples of bug summaries that are less useful:

  • Can foo be added to the tree?
  • bar is a dictionary
  • It would be cool to have libbaz if we get foo

This page is to be extended

We will need to document our practices and useful resources here (QA reports, good bug queries, ...).

Criteria for closing a report

Each request is important and was made by a real user, so must be carefully evaluated prior to closing. While it is not useful to have thousands of open requests, it's also harmful to unnecessarily close requests that are still valid.

Use these guidelines to help evaluate whether a request still has merit:

Metric Weight Notes
Upstream status
Exists High Package must still be available and fetchable (did it move to github, bitbucket, ...?)
Alive Medium Signs of activity - releases, commits, bug reports, mailing list?
Technical debt
Dependency availability High Cannot require ancient dependencies that are no longer available (qt3, kde3, ...)
Toolchain High Needs to build in a modern system (recent GCC, glibc, ...)
Suitability
License High Package license must be a good fit for Gentoo
User demand Medium Is there continuing interest in the package, or interest from multiple users?
Wider availability Medium Do other distros package it?

Project's relationship to Bug wranglers

This project attempts to fit side by side with Bug wranglers.

Bug wranglers is a project for bug assignment. Having a separate mail alias and project page makes it easier for people as a separate form of contact, documentation, and recognition.

Retrieved from "https://wiki.gentoo.org/index.php?title=Project:Bug-cleaners&oldid=1305824"