No frozen rawhide announce plan

Participants 2010-02-12

• Jesse Keating
• John Poelstra
• James Laska
• Luke Macken
• Paul Frields

Ultimate Goal

1. Provide a single URL that we can reference in all communication about no frozen rawhide now, and Alpha Freeze/branch in the future

NFR Benefits

Flesh this out
More supporting information likely can be found in the original proposal page. We should clarify why this process happens the way it does, and what led to this redesign.

a developer can always get a recently built package into a repo (do not pass pending updates-testing)

Places We Want To Get Word Out

1. devel-announce list
2. test[-announce] list (includes test@ and devel@ lists)
3. (micro)blogging
4. IRC (#fedora-devel, #fedora-qa, #fedora-bugzappers)
5. Fedora forums
6. Internal RHT contacts (blast to developers)

Next Steps

1. wikify this information
2. fix all the FIXMEs
3. Draw a picture or special page for the "Misc" section (explaing trees, repos, etc.)
4. Draft announcement emails
5. Meet again on Tuesday to touch base

Action Items

1. poelstra will wikify the gobby session to serve as a work items (by Monday at latest)
2. poelstra will "wikify" our Tree/Repo overview (first pass by Tuesday)
3. jkeating will update the ReleaseEngineering/Overview page with the Tree/Repo overview (by Tuesday)
4. jlaska will propose an updated Releases/Rawhide page
5. PaulF will get us some volunteers to help create some wiki pages
   • will work on creating missing wiki pages from these notes
   • ReleaseEngineering/Overview page (or some sort of developer overview page) will serve as the starting point for all of this stuff
   • No_frozen_rawhide_wiki_updates -- breaks out pages into a table where we can track progress

Existing Documentation

• http://fedoraproject.org/wiki/ReleaseEngineering/Overview
• https://fedoraproject.org/wiki/Releases/Rawhide
• https://fedoraproject.org/wiki/QA/Join#Testing_Rawhide
• http://fedoraproject.org/wiki/No_Frozen_Rawhide_Proposal
• http://fedoraproject.org/wiki/No_Frozen_Rawhide_Implementation
• http://fedoraproject.org/wiki/Package_update_HOWTO
• http://fedoraproject.org/wiki/PackageMaintainers/Package_update_guidelines
• https://fedoraproject.org/wiki/Releases/13/Schedule
  • still mentions Alpha Freeze, but it is probably "Alpha Milestone"
  • does not mention Branch Freeze/Branch Event
  • duplicates Important Release Milestones
• https://fedoraproject.org/wiki/Important_Release_Milestones
  • still mentions Alpha Freeze
  • does not mention Branch Freeze, only Branch Event
  • does not mention Bodhi for getting non-critical packages into branch-frozen package set
  • Branch Event date may be at "Alpha Milestone" instead of at "Feature Freeze"
  • does not contain all dates form Releases/13/Schedule, e.g. Alpha Release is missing
  • does not mention GO/NOGO date for releases, e.g. 2010-02-24 20:00 UTC for Alpha Release accoring to Fedora 13 Alpha Release Criteria
• http://poelstra.fedorapeople.org/schedules/f-13/
  • duplicates Important Release Milestones and Releases/13/Schedule
  • contradicts Fedora 13 Alpha Release Criteria 20:00 UTC vs. 20:00 EST for the GO/NOGO meeting (probably also for other GO/NOGO meetings)
  • mentions "End Alpha Freeze" which does not exist anymore
  • does not mention branch freeze

When will NFR go Live?

• branch source control AND trees/repos on day of Alpha freeze (2010-02-16)
• between GA of previous release and Alpha freeze there is NO "pending" tree or repos (rawhide is the only thing)
• What audience of people will need to know? What will their questions be? (see use cases below)

Use Cases

Developer

1. Jean wants to build a package for rawhide
   • Jean checks out and builds from the devel/ branch.
2. Jean wants to to make her built package for rawhide available for testing
   1. Happens nightly automatically. No action required by Jean.
3. Rudy wants to build a non-critical path package for Fedora 13 (branched content that is Fedora 13 in development)
   • Rudy checks out and builds from the F-13/ branch.
4. (same as case 7) Rudy wants to to make his built package for Fedora 13 available for testing
   1. Rudy requests a testing update in Bodhi for Fedora 13. Bodhi admins "push" it.
   2. Peers test the update and provide karma feedback via bodhi
5. (same as 8) Rudy wants to make his testing update "stable" and tagged for Fedora 13.
   • Rudy requests a push to "stable" within Bodhi. Bodhi admins "push" it.
6. Gilbert wants to build a critical path package for Fedora 13 (Pending)
   • Gibert checks out and builds from the F-13/ branch.
7. (same as case 4) Gilbert wants to make his built package for Fedora 13 available for testing
   1. Gilbert requests a testing update in Bodhi for Fedora 13. Bodhi admins "push" it.
   2. Peers and members from QA or Releng test the update and provide karma feedback via bodhi
8. (same as 5) Gilbert wants to make his testing update "stable" and tagged for Fedora 13
   • Provided the package has net positive Karma from QA or releng and at least one more net positive karma point, Gilbert requests a push to "stable" within Bodhi (this could be automatically done if karma autopush is checked). Bodhi admins "push" it.
9. Cletus has built a package to handle an urgent issue (e.g. security problem, non-functioning system, etc.) and wants to push it to the Fedora 13 branch.
   1. Cletus builds in the F-13 branch and creates a bodhi update and does one of the following:
      1. in all cases, Cletus needs to be very very very sure the update will not cause additional problems
      2. if the package is not in the critical path, nor addressing a security problem, then Cletus requests a push to stable.
      3. if the package addresses a security issue then Cletus marks it as security and waits for the Security team to sign off on the update (not sure how this happens right now) before requesting the package be pushed to stable.
      4. if the package is in the critical path, then Cletus also waits for a QA/releng/peer net positive karma vote in Bodhi before requesting the package be pushed to stable.
10. Arnando has a package in the "pending" updates-testing repo for a week that hasn't received karma feedback
    1. If the package is in the critical path...
       • Arnando needs to query QA/releng and peers to recieve karma for his update before he can proceed
    2. If the package is not in the critical path...
       • Arnando can choose to push to stable, or request and wait for further testing
11. Kelly wants to build a new package, but isn't sure if it should go to Rawhide or Fedora 13
    1. New packages should always be built at least for Rawhide
    2. New packages can be built for Pending and existing Fedora Releases, however they should go through updates-testing first. If the new package is critical-path it will require net positive karma from releng/qa and peers as outlined above.
12. Berta wants to build a package for the Pending Fedora 13 but it requires package that is not yet pushed "stable" for Fedora 13.
    1. Berta would need to file a buildroot override tag request as outlined in the policy page Alpha_Freeze_Policy
    2. Once tagged, Berta can proceed to build her package and issue the bodhi request
13. Jeff wants to check and see if his build will be in the Fedora 13
    1. Builds that will be in Fedora 13 will be tagged with dist-f13. Jeff can run koji latest-pkg dist-f13 <package> to see what the latest build of his package is for Fedora 13

Tester

1. Jane wants to install 'rawhide' on her system to test the latest and greatest packages at all times
   1. Jane reads the http://fedoraproject.org/wiki/Releases/Rawhide wiki page and follows the instructions to get rawhide installed.
   2. Jane leaves the rawhide yum repo enabled and keeps fedora, updates, and updates-testing repos disabled.
   3. Jane consumes the rawhide firehose and reports issues as she finds them.
2. Jimmy wants to install and run the 'pending' Fedora release (aka Fedora 13) as his desktop and to participate in test days
   1. Jimmy installs from Alpha, Beta, the Last Known Good Pending snapshot or from a Pending nightly live image
   2. Jimmy yum updates to the latest pending content
3. Jill wants to update her Fedora 12 system to the Pending Fedora 13 and start testing Fedora 13
   • Jill updates her existing Fedora 12 system by reading instructions at FIXME
4. Beatrice wants to pitch in and provide test feedback for new packages ... where does she go? ('Rawhide', 'pending' updates-testing, 'stable' updates-testing)
   • Beatrice would check the QA/Join page that describes the different testable repos and skill level and investment involved. She would make a decision and follow documentation on how to test.
5. Pat wants to impress his friends by becoming a member of the QA team so that he can represent QA in providing positive feedback on critical path package updates on the 'stable' and 'pending' fedora releases
   1. Pat reads the QA/Join page and demonstrates an ability and desire to do the testing and provide useful feedback and applies for the official QA group
   2. Pat reads the QA:Package Acceptance Test Plan and uses it as a guideline to test things.
   3. Tangent - We have a completely unused 'qa' FAS group ... do we wipe the list and start over? (It's possible to do that, but before you do, you can email 'qa-members@fp.o' to take care of advance notice... i.e. give people a heads-up, make sure everyone understands why, and what they should do next, whether it's join another group, speak up to keep membership, or what have you)
6. Desmond is a member of the QA FAS group. Desmond provided positive feedback on a 'pending' or 'stable' package update. The package update is released and includes a major regression. What now?
   1. Would review in weekly QA meeting. It's ok, mistakes happen
   2. Accident/omission
   3. Misuse

Mirrors

1. Frank is a mirror admin and wants to prepare for additional repos coming to his mirror
   • Frank reads mirror-list(-d) and watches for announcements regarding new paths being added to the master mirror
   • Frank checks his sync exclusion settings to ensure he either gets, or doesn't get the new path depending on his desires.

Other

1. Fabio can't figure the difference between 'rawhide', 'development', or 'pending'. Fabio wants an overall understanding of the release naming and repos. Where can he find information on which one is suitable for him?
   • Fabio would go to our new and improved Fedora Development Process Overview page FIXME
2. Where can Roscoe go to understand how the paths of rawhide and pending work?
   1. New contributors (manditory reading), new testers (highly suggested reading), new consumers (useful reading), anybody interested in how Fedora is developed would find this page useful.
   2. http://lists.fedoraproject.org/pipermail/devel/2010-February/130504.html (idem)No_Frozen_Rawhide_coming_soon New Paths on mirror!
      • Most of these questions are answered by our overview in the last section

Tree/Repo Overview

• Important distinction between tagging before a build and tagging in source control.
  • If tagging AFTER a build you are talking about tagging in Koji
• What do we call the stage of tree when we have branched away from rawhide? Pending is working name

  1) "rawhide" (aka 'development') (TREE)
       |  packages built from devel/ source control branch
       |  rawhide repo (mirrored)
       |  install images (not created nightly, not mirrored)
       |  live images (created nightly, not mirrored)
       |  path == development/rawhide
       ▼
  2) "pending"  <could use a better term?> (this is the {pending,in process} tree) TREE   <--- enactment of NFR
       |   packages built from F-##/ source control branch
       |   bodhi:: pending tree Repo (Alpha/Beta/GA come from this repo)
       |   bodhi:: updates-testing Repo ("freeze-break" candidates for the release)
       |   install images (attempted nightly creation, mirrored)
       |   live images (created nightly, not mirrored)
       |   path == development/##
       ▼
  3) "Fedora 13" (final GA/GOLD) TREE
       packages built from F-##/ source control branch
       GA Repo (static)
       bodhi:: Updates Repo
       bodhi:: Updates-testing Repo
       install images (mirrored along side repo)
       live images (mirrored)
         path = releases/##