[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]

Interim New Package Process

(Until we can agree on a better process with better tools, I propose this simple process to operate Extras at least during the next 2 weeks. I really think this process is horrible, but we need SOMETHING to work from rather than unwritten rules for the short-term. We will be arguing about details for the final process between now and FUDCON.)

Contibutor Levels (jargon needed to understand the process below)
(Highest) "Trusted" or RH FC Engineer
These people can sponsor "Contributor" membership, where they take responsibility for the new member to have full CVS access. These members can veto (or stall) "Contributor" nominations or new package additions and force a discussion, vote, or something. (Currently everyone with CVS access is also "Trusted", but that may quickly change as we accept many more members in the coming weeks.)

(Middle) "Contributor"
These members can sponsor new package additions and act as intermediaries for those who do not yet have CVS access. Contributors have full CVS access but are expected to respect package ownership. These members can veto (or stall) new package additions if there is good technical reason.

(Lowest) "Packager"
These members own packages in Extras but are not sponsored. They can get CVS access to their own packages. Their goal is to show competency and hard work in order earn trust so someone will sponsor them. (We may not be able to create Packager status accounts until the database driven account management system goes into production.)

Interim Extras Package Process
You can add a new package if it meets these requirements:
* Another Extras Contributor or RH engineer (but not yourself) to sponsor your package.
* No known legal/licensing problems.
* Nobody vetos it.

Use cvs-import.sh from the common module. If you do not have CVS access, then convince a package sponsor to checkin for you. That package sponsor is probably the same person who does the package review.

Package should comply with most of the packaging best practices (yet to be rewritten) so it is of reasonably good quality. This is FAR LESS than strict QA requirements of fedora.us. Judgement of the reviewer of "good enough". Package quality can be fixed AFTER import but before build.

In most cases it would be safe to push a less than certain package, and use resulting testing to fix it quickly and push again. However if it would endanger existing users, or other packages, then don't do this. Again up to the judgement of the reviewer.

After a package has been reviewed, post to
fedora-extras-commits redhat com with
Subject "APPROVED: packagefoo, packagebar, packagebaz..."
Body should contain package names, short descriptions, who reviewed, and who will maintain those packages.

(This is so we can easily search where a package came from, and who
reviewed it.)

Edit this page and add a request for a new Bugzilla component.  Include
1) Package name
2) Description (from Summary field)
3) Bugzilla account e-mail address of package owner

For example:
foommoorpg:Totally Awesome and Free 3D Online RPG Game:bob somewhere net
foommoorpg-data:9GB of Data for Foo MMORPG:bob somewhere net
footrainer:Cheating Program for Foo MMORPG:bob somewhere net

Edit this page and add your package to the "build needed" section.

For example:
* foommoorpg (i386, x86_64)
  * foommoorpg-data (noarch)
* footrainer (i386, x86_64)
* fooutil (i386 only)

Just do it, or funnel it through the package sponsor if you don't have CVS access yet.

Warren Togami
wtogami redhat com

[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]