Fedora packaging flow outline ================================ 1. A person self-selects to package content for the Fedora Project as a volunteer. 2. That "Packager" generates a GPG key set, and publishes it to an appropriate public keyserver. They may solicit signing of that Public key from others in the Fedora project or elsewhere. 3. That Packager identifies a package, with suitable license, and free of intellectual property encumbrance, to package. 4. That Packager sets up an appropriate build environment, prepares a .spec file, and refines it and the build environment, until a clean repeatable build on a supported target is produced. 5. That Packager transfers the two items, SRPM and tarball, to the project's incoming directory, and completes the "Request for QA" webform. =============================== 6. The "Request for QA" webform will only offer to accept a post after it has received a submission of content who have uploaded the two required files, duly signed and able to be duly verified against an independent retrieval of the corresponding Public Key, based on key-id from an appropriate public keyserver. 7. Non-verifying uploads will be silently deleted periodically. 8. The "Request for QA" webform backend will assign a QA batch number sequentially, and inform the Packager, who is then also a "Submitter" of that tracking number. 9. The "Request for QA" webform backend will move incoming 'submitted' content to the 'Holding Pen' =============================== 10. The Holding Pen shall be indexed no less frequently than daily using the Rpm2html / Rpmfind mechanism, and shall be linked on the Fedora website. =============================== 11. A QA reviewer shall perform the following steps: a. Review the pending QA batch description b. Review the rpm2html description of a package which possibly interests them. c. If indeed the QA reviewer undertakes to review a package, the reviewer shall complete the "Intent to Review" form. =============================== 12. Access to the "Intent to Review" form and its reports shall be restricted to authorized QA reviewers, and for their packages only, to Packagers. 13. The "Intent to Review" webform backend shall record the identity of a QA reviewer who expresses an intent to review, and shall display the number of QA reviewers 'working' on a given batch. 14. A QA reviewer: a. shall compare the submission to the technical building standards for conformance, b. may assert that the package seems functional. c. may choose to advise the Submitter of perceived non-conformance areas, informally for modification d. may advise the "Voting Booth" webform of a Positive, Conformant, or Negative QA test result on that batch. =============================== 15. The "Voting Booth" webform shall record the identity of a QA reviewer, and their result for a given batch, and any optionally stated reason. 16. If a batch attains N non-Negative QA reviewer votes, it shall be released to Building, Signing and Slotting. 17. The Packager may withdraw a batch at any time prior to a release to Building, Signing and Slotting. All QA reviewers on that batch shall receive notice of such withdrawal, and any optionally stated reason. =============================== 18. Building for release shall consist of an automated build of the SRPM, according to %{name}-%{epoch}-%{version}-%{release}-environment.txt on all target result platforms. 19. The Signing shall consist of a GPG signing with an official Fedora key of the SRPM, and any resulting Release Binaries. 20. The Slotting shall consist of categorizing the results appropriately as to maturity, according to Fedora criteria. ============================================================== Standards: =============================== S-1. All builds shall be performed as non-root, from a SRPM, using a build method which creates all target binaries and a new SRPM. The process shall then be repeated with the produced SRPM, to produce the same elements again, to yield all target binaries and a second produced SRPM. This applies to both Packager and QA building. S-2. The build environment shall be a pristine install of a given Distribution, at a stated Major and minor release, and shall have all updates applied. Additional packages as needed to effect the build shall also be permitted, so long as the sources for them are also freely available from a stated source, and with suitable license, and free of intellectual property encumbrance. S-3. The Packager 'deliverables' which constitute a test candidate shall be as follows: a. the second produced SRPM, signed with that person's GPG key. b. a tarball, named %{name}-%{packager_userid}-%{epoch}-\ %{version}-%{release}.tar.gz, consisting of files named %{name}-%{epoch}-%{version}-%{release}-stdout.txt, %{name}-%{epoch}-%{version}-%{release}-stderr.txt, %{name}-%{epoch}-%{version}-%{release}-environment.txt, an optional %{name}-%{epoch}-%{version}-%{release}-report.txt, and a GPG-signed MD5SUM.asc of the foregoing files, produced in a relative directory tarball fashion S-4. All testing candidate SRPMS shall consist of ONLY the following: a. pristine sources, freely obtainable from the location specified in the URL: tag b. unified or context diffs against pristine sources c. the .spec file S-5. The %{name}-%{epoch}-%{version}-%{release}-environment.txt report shall be produced thus: rpm -qa --qf '%{name}\t%{epoch}\t%{version}\t%{release}\n' | \ sort > %{name}-environment.txt Manual comments, preceded with the customary "#" at column one, may also be added. S-6. The optional %{name}-%{epoch}-%{version}-%{release}-report.txt shall note any special communication or instructions for the QA testers. It is not an external document, and shall not be released generally. S-7. The MD5SUM.asc shall be produced thus of each tarball element, preferably in a clean sub-directory: touch `ls` md5sum `ls` > MD5SUM and then duly --clearsign'ed S-8. All 'tar' operations shall be done with the GNU tar package. The computation of the md5sum shall conform to Request for Comments 1321 and be performed as to a binary file variant. S-9. Web of trust matters; A careful key signer will verify a key offered for signing several ways: By comparing the fingerprint of the key to several diverse archives of reliable character; By ascertaining the contact information of a purported key owner against formal Whois or other well known directories; By formal physical comparison of suitably official identity indicia. By formal contact with the purported key owner, which contact might be telephonic. Each signer shall undertake signing with solemnity, and not with an attitude of 'racking up' a large collection of counter-signatures. ========================= /home/herrold/fedora/fedora-flow.txt RPH - master on: couch initial 030213 Rev 030427 - RPH - one typo, added epoch hooks, clarified S-2 build dependencies, to match initial release of ftp://ftp.owlriver.com/pub/local/ORC/fedora/ORC_flow_build Rev 030222 - RPH - fixed typos, numbering error =================================================== Copyright (c) 2003 R P Herrold, Columbus OH, info@owlriver.com Any derivative work must retain this Copyright notice, and shall reference: http://www.owlriver.com/projects/fedora/fedora-flow.txt ===================================================