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 initial pre-sponsorship period.
• Checkin and initial builds.
• Maintenance, updates, etc.

Packages also go EOL or are handed off to others and occasionally packagers 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.

The pre-sponsorship period

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.

Note: I'm assuming that the recently-approved maintainer containment procedure is in place.

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 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.
• 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.

Proposal: an interface for submitting packages for reviews. Allows for an src.rpm to be uploaded, builds it, 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.

The package process

Post review

Maintenance Rebuilds Periodic re-review