User:Tibbs/Packager and Package Care

This document is an outline of the duties of an entity within the Fedora project overseeing the care of packagers and packages within the distribution.

• I believe this entity should be FESCo. If it is affirmed that FESCo should handle this, I intend to stand for election. If it is decided to assign these duties to a separate committee, I'd like to be on it.
• I place "Packager" before "Package" because while the distribution is composed of Packages, they don't maintain themselves. Without packagers, there is little to actually distribute.
• Both packagers and packages are covered because both need attention and I don't believe it's possible to separate them in any meaningful way.
• This is a brainstorm of both what I think the committee should handle and various ideas I'd like it to pursue.

Scope of committee/SIG involvement

The committee/SIG should be involved in all phases of both packager and package lifetime. This basically amounts to refining proposals and directing what effort is available towards implementing them.

Packagers and packages go through several stages together:

• The review period (which may also require sponsorship)
• Checkin and initial builds.
• Maintenance, defect management (including triage), updates, etc.

Packages also go EOL or are handed off to others. Packagers start in a non-sponsored state and have their status upgraded and will occasionally leave the project.

The committee/SIG should oversee all of this, resolving disputes where necessary, identifying bottlenecks or problem areas and directing effort at solving them. Disputes can occur at almost any stage of the process, and the committee needs to be prepared to step in wherever necessary.

Per-sponsorship and initial review

New packagers must go through a somewhat arduous process over and above the difficulty of learning how to actually package software. Our procedures are extremely front-loaded; the procedure gets simpler once a package is in but initially it's pretty tough to navigate. Some of this (such as the new account and CLA process) is beyond the scope of packager care and has gotten much easier lately, but we still have several complicated processes involved.

Users basically have to post a package somewhere, and create a review ticket. They have to manually set up things like the NEEDSPONSOR blocker.

This breaks down for several reasons:

• They have to find outside hosting for their first package; fedorapeople.org doesn't work for them until they're already sponsored.
• While it's technically possible for them to do koji scratch builds if they have the arcane knowledge, we don't document this and honestly given the complexity of the process it wouldn't be fair to ask them to do this in addition to everyone else. Unfortunately this results in an annoyingly high rate of package submissions which don't build.
• They're progressing through a long procedure; if they miss or confuse a step then it takes a reviewer to help them work things out. Sometimes it's not easy to know when a review submitter has neglected to block the NEEDSPONSOR ticket because it's not easy to map from the address in bugzilla to the FAS account name.
• Especially for NEEDSPONSOR tickets, the wait for review may be quite long with no feedback or progress given. Maintainer containment may help significantly here.

Some ideas for helping:

• Review ticket triage. With some basic procedures and a few volunteers, we could at least weed out the packages that don't build and get rpmlint output into the tickets so that the reviewers wouldn't have to spend so much time. We could also give some feedback to those who have been waiting for months for someone to look at their packages, and identify tickets where the submitter has regrettably lost interest.
• An interface for submitting packages for reviews. Allows for an src.rpm to be uploaded, builds it in koji, provides rpmlint output and if things built OK, hosts the spec and src.rpm, allows the user to enter the rest of the review info and creates the review ticket. Obviously there's a lot left to think about and a ton of effort required but even doing some of this could help.

For the packager's second and further packages, things get simpler. They've seen the process, generally know how to use koji and may know how to do a scratch build. They don't have to wait for a sponsor. However, they do still have to wait for a review, and reviews are complicated in any case.

Proposal:

• A package review utility. Make it easier and less time consuming for reviewers by providing a basic GUI interface to the review process. At its simplest this could just be a checklist; more complicated possibilities include providing a list of open reviews, doing the bugzilla work of assigning tickets and setting the flags, pasting in a filled-in checklist, downloading and unpacking SRPMs, allowing browsing of the source tree, fetching upstream source and doing the comparison, parsing some things out of the spec (License:, etc.) and tons of other things. It isn't possible to replace the human or to do everything necessary for a review, but it should be possible to build something that helps.

CVS admin and checkin

This isn't terribly complicated; it would be nice to reduce the round-trip through the CVS admin (perhaps by allowing the reviewer to initiate the CVS admin bit themselves) but currently this happens pretty quickly.

We do have nothing in place to ensure the package which was reviewed is the one that is checked in. After checkin all changes are logged and broadcasted but this is a significant window where anything can happen. If the reviewer did the CVS admin as above, they could also do the initial checkin.

Package build and push

These are pretty good at the moment; make update really helps. Some might perhaps wish for a GUI wrapped around the process, but I don't see this as a priority.

Maintenance

The triage team is going a good job of helping out with bugs; they could certainly use more help but I don't see much else that could be done.

Currently there's not too much in the way of post-commit review. We have the FTBFS system which has recently come up helping somewhat, and various reports about broken dependencies, upgrade paths, Source: URLs and such. These are all good and they do help, but we certainly need more. Periodic rpmlint runs would be nice (with an opt-out mechanism, for either specific complaints or the whole thing) and periodic re-reviews would be great if the new package review queue was down at 20 instead of 800. Definitely open to suggestions here.

FESCo has already approved various responsibility policies relating to package maintenance.