Gentoo Grumpy Project

1.  Project Description

Maintainers spend an inordinate time doing chore works that could be automated. This project intends to do just that for them - automate and centralize a lot of that to save maintainers time and brain cells.

2.  Project Goals

There are many moments in every package maintainers life when she wishes one or another thing would be done automatically for her. What packages I maintain have a newer version available that is not packaged yet? What packages have identified common QA issues? What packages could be stabilized if following the 30-day guideline? And so on. If such questions plague you often to save your time, this is the project to help with!

Many such automated or semi-automated software does exist, but they are currently dispersed across the Interweb in various different locations, with typically no good connection between packages and the maintainer looking at the information. GPNL, tinderbox rindex/dindex reports, gentoo-bumpchecker, manual repoman/pcheck runs, and so on.

Project codenamed "Grumpy" is intended as a Gentoo Linux project to aggregate all these tools functionality into one centralized website and add more such maintainer time saving functionality into a coherent whole.

grumpy maintainer helper - because it's better to have a website be grumpy than a maintainer.

A one stop shop for finding out what options of work you, as a package maintainer, have at that moment in regards to your various package maintainerships.

3.  Developers

All developers can be reached by e-mail using nickname@gentoo.org.

4.  Examples

Perhaps some examples of what such a website could entail in itself (but these are merely examples)

1. Ability to tell it what packages you maintainer or are interested in based on a listing of herds or maintainers, to be able to primarily view reports about packages of main interest.
2. Automated version tracking between Gentoo stable tree, testing tree, overlays and upstream releases. Reports on what version bumps or stable requests could be done.
3. Various up to date QA reports of packages maintained.
4. High-level overview of all the tasks possible thanks to the centralization.

5.  Team Members

Suggested course of action after initial discussion is of course for a team of interested developers/contributors rally together and start researching the options for implementations.