From Fedora Project Wiki

Revision as of 06:50, 12 November 2014 by Matthewcline (talk | contribs) (Added link to Package Review Process at top of page)

NOTE: The current equivalent of this page is Package Review Process

Old Package Submission and QA Policies used at fedora.us

This is a copy of the old document from fedora.us.

Procedure for Submitting Packages

1. Post a Self-Introduction to fedora-devel-list@redhat.com including the items listed on our Self-Introduction list.

  • Make your src.rpm package conform to the PackageNamingGuidelines.
  • Check that your package conforms to the QAChecklist.
  • Sign with your GPG key (Fedora GPG mini-HOWTO ).
  • Upload to a web accessible server.
  • Submit new Bugzilla > Fedora Meta > Package Request. File updates of existing packages in the repository against the proper product/component instead of Fedora Meta.
  • Here is a good example of what to include
  • Direct URL to package.
  • Direct URL to GPG clearsigned md5sum file (optional, as the package was signed with your GPG key...).
  • md5sum *.rpm | gpg --clearsign > md5sum
  • Short description of what the package is. Eg. copy-paste the description from the spec file into the first comment and describe the package in the bugzilla ticket summary.
  • After submitting the report, always add a few bugzilla keywords to the Keywords field of the bug:
  • QA
  • This keyword indicates that the package is in need of QA testing and makes the bugzilla ticket appear in the list of packages waiting for QA .
  • stable, testing, or unstable
  • Indicates which repository you think it should go.
  • UPDATE
  • If the package is an update to an existing one in the repositories, add the UPDATE keyword and file the package request against the bugzilla product/component of the current package.
  • COMMON
  • Indicates that the same binary/source package, usually without the "disttag", can be built and published for all target distribution versions.
  • (also add one or more keywords for the target distribution)
  • Change the priority level to the level where you think it should go, P1 being most important and P5 being least important. QA testing should focus on higher priority requests first, so more important packages get into Fedora sooner than less important packages.

QA Testing Procedure

Package submissions in the QA Queue are stored in Bugzilla. At this point a package will only be published after it has been approved by the QA process where other developers check the package against the QAChecklist, and satisfies the Publish Criteria . In order to expedite the process, encourage other packagers to thoroughly check your package by doing a good job in QA testing of their package.

If you have not already, please post a Self-Introduction to fedora-devel-list@redhat.com including the items listed on our Self-Introduction list.

QA comments in Bugzilla should preferably be clearsigned. In cases where a QA message would lead to package approval or publication, the message MUST be GPG clearsigned, and contain md5sums of the reviewed source RPM as well as preferably all upstream sources. The source RPM md5sum is mandatory in order to be sure that the package to be built is the same as the reviewed one. GPG clearsigned messages that give good advice can all be traced back to your GPG key and accumulate over time. This process allows new developers to gain trust through technical correctness and hard work over a period of time, eventually being able to prove to the community that the developer can be trusted.

If QA comments are submitted listing things within the package that should be fixed, the original packager should update their src.rpm or respond why they feel suggestions are not valid. Be sure to increment the vepoch number (see PackageNamingGuidelines section C-2) before building the new SRPMS. Upload the new src.rpm packages along with updated clearsigned md5sums to your web server.

If the package contains flaws that must be fixed, set the NEEDSWORK keyword, and remove QA. For packages which satisfy the Publish Criteria , remove QA and add PUBLISH. If your "+1" review is the first one and you are not a "trusted" reviewer, add the REVIEWED keyword (and keep the QA).

Procedure when Ready for Publication

If the package meets Publish Criteria , QA tester does ... 1. Remove keyword "QA".

  • Add keyword "PUBLISH". gpg --clearsign affirmative comment so it is verifiable, and include at least the md5sum of the reviewed source RPM.

Release Manager does ... 1. Send src.rpm to build system.

  • Send resulting rpms to signing server.
  • Sign
  • Post candidate builds
  • Change bug status to RESOLVED PENDING

Verification of built packages -- the PENDING status

Packager or other trusted QA do... 1. Download and verify functionality of candidate binary packages. Add the Pending Repository to your apt/yum sources.

  • If satisfied, mark bugzilla ticket as VERIFIED. Use the radio buttons below the comment input field to do that. gpg --clearsign affirmative comment so it is verifiable. Be also sure to include something that uniquely identifies the package in the clearsigned comment to prevent it from being copy-pasted to other contexts. A full name-version-release string of the downloaded binary package is a good example.
  • If it needs more work, Re-Open bug and comment. Any other visitor, who thinks something is wrong with the candidate binaries, please add a comment in bugzilla.

Release Manager does... 1. Bugs in VERIFIED status are published into Fedora tree.

  • Set to CLOSED.

Packager does... 1. Send a GPG signed announcement to the fedora-extras-announce mailing list. In the fedora-rpmdevtools package you'll find a script called fedora-pkgannfmt which generates announcement messages. If the announcement is for an updated package, include only the changelog entries since the previous released version. See the mailing list archives for more examples.

  • Note that fedora-extras-announce is a moderated list. Do not worry if your announcement doesn't appear instantly, posts are frequently reviewed and approved by the list moderators.
  • This list was renamed and restarted when it was moved to Red Hat's server. Here's a link to the old fedora-package-announce list archives .

Duplicate package submissions

Before packaging something, it will a good idea to check if someone else has already done so. Checking the main package repository is obviously a good idea, but you should also search Bugzilla for any related package submissions.

Even if there already is a package, you may still submit a suggested update.

Package update submissions

If the update is for an already published package, make sure that you file it using the correct component and that you set the UPDATE keyword.

Life cycle of a UPDATE submission is illustrated in the following diagram.

http://www.fedora.us/docs/update-process.png

  • See Extras/Old/FedoraPeople for lists of people in various roles.
  • People in any role can "downgrade" their rights regarding any part of the submission process, if they wish. In other words, release managers can act as trusted or non-trusted developers, and trusted developers can act as non-trusted developers. For example, a trusted developer may choose to do the QA->REVIEWED step, instead of having to go QA->PUBLISH; or to submit packages with the QA (instead of PUBLISH) initial state if in doubt about something wrt. the update.
Retrieved from "https://fedoraproject.org/w/index.php?title=PackageSubmissionQAPolicy&oldid=394529"