orion / stewardship-sig

Forked from a deleted repository 4 years ago
Clone
README.md

Tracking Project for the fedora Stewardship SIG

Data and code in this git repository is either released into the Public Domain, or licensed under the terms of the Unlicense license text contained in the LICENSE file, whichever is applicable wherever you are.

There's also a Wiki page for this SIG.

An up-to-date overview of our packages can be viewed in this Google Docs spreadsheet.

IRC and Meetings

The #fedora-stewardship IRC channel on freenode is used for synchronous conversations. Meetings are held bi-weekly in the #fedora-meeting-1 channel, at 15:00 UTC every other Tuesday (starting April 30, 2019).

Mailing List

The private stewardship-sig fedora mailing list is used for announcements, BugZilla E-Mails, and asynchronous conversations. New members will be added to this list automatically.

Maintained packages

The list of packages that are currently maintained under the Stewardship SIG umbrella can be found on the group's page on src.fedoraproject.org.

If you are curious of one of your packages (transitively) depends on a package that is maintained by this SIG, you can use the intersection.sh script to check the intersection between your package's dependency tree and the packages maintained by this SIG.

Package build status

The current build status of all packages can be seen on the koschei page for the Stewardship SIG group.

Package dependencies report

The report at https://decathorpe.fedorapeople.org/stewardship-sig.html is generated by running the generate_report.py script, and is refreshed regularly after successful rawhide composes to keep up with the latest package changes.

Pull Requests report

All open pull requests against our packages can be viewed at https://decathorpe.fedorapeople.org/stewardship-sig-prs.html. It is generated regularly by running the generate_pull_requests_report.py script.

Contents of this repository

This repository is organized into several components:

  1. README.md -- this document
  2. data/ -- machine-readable statistics and data about SIG packages
  3. scripts/ -- a collection of scripts and data for SIG operations
  4. dependents/ -- information shared by our dependent packages

Packages we need or want to keep maintained "indefinitely"

There are a few packages that we want to keep maintained, even if no proper new maintainer wants to pick them up in the near future. Others we want to keep in a working (and building state), but we don't maintain the packages themselves:

  • ant
  • dogtag-pki (deps only)
  • jgit (deps only)
  • libreoffice (deps only)
  • maven

Bi-weekly package cleanup procedure

Our regularly generated report includes a list of "SIG leaf" packages, which are not depended upon by any other package maintained by this SIG. Every two weeks, @decathorpe will notify maintainers whose packages directly depend on these packages, and ask that one of them to pick it up as a "proper" maintainer.

The reasoning behind this is that the maintainers of dependent packages are probably the people who are most likely to take care of these packages, if only to keep their own packages working.

However, if no such "adoption" request is made within two weeks after the announcement, the packages will be orphaned again, and set towards retirement in an additional 6 weeks, as usual.

This gives maintainers of dependent packages a total of 8 weeks to request ownership of relevant packages. So think of this procedure as an extension of the existing process for the regular retirement of orphaned packages that gives maintainers of dependent packages even more time to act.

How to help

Most of our packages are looking for new, permanent maintainers, so if you are an experienced packager and want to take some packages off our hands, open a new issue and fill out the package adoption request template.

Adoption Procedure (our side)

To make sure we won't continue to get spammed by bug reports for packages no longer under our purview, the following steps should make sure no references to the Stewardship SIG are left when packages are assigned to a new, permanent maintainer:

  1. remove @stewardship-sig from the package ("Settings" / "Users & Groups")
  2. give package to the new maintainer ("Settings" / "Give Project")
  3. remove yourself from the package (optional), ("Settings" / "Users & Groups")
  4. remove the group from the bugzilla contact overrides (if necessary), by opening a Pull Request at releng/fedora-scm-requests

For "adoptions" that are handled via tickets, @decathorpe will automatically handle resetting the default RHBZ assignee regularly.