No edit summary |
No edit summary |
||
| Line 7: | Line 7: | ||
== The | == The process == | ||
New packagers must go through a somewhat arduous process over and above the difficulty of learning how to actually package software. 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 | New packagers must go through a somewhat arduous process over and above the difficulty of learning how to actually package software. 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 com | ||
Note: I'm assuming that the recently-approved maintainer containment procedure is in place. | Note: I'm assuming that the recently-approved maintainer containment procedure is in place. | ||
=== Initial | === Initial package submission and sponsorship === | ||
Users basically have to post a package somewhere, and create a review ticket. They have to manually set up things like the NEEDSPONSOR blocker. | 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 because | 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. | |||
=== Elevation to supergroup === | === Elevation to supergroup === | ||
Revision as of 01:26, 10 June 2008
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 while
- This is a brainstorm of both what I think the committee should handle and various ideas I'd like it to pursue.
The process
New packagers must go through a somewhat arduous process over and above the difficulty of learning how to actually package software. 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 com
Note: I'm assuming that the recently-approved maintainer containment procedure is in place.
Initial package submission and sponsorship
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.
Elevation to supergroup
Elevation to sponsor
General issues
The package process
Review
Checkin
Post review
Maintenance Rebuilds Periodic re-review