Managing changes in open source projects
summary
Describes Fedora’s concrete change workflow: proposals live on a tracked page, require test and contingency plans for system-wide impact, and get technical approval from FESCo nine-person elected body. Tooling is moving from wiki pages to moving from wiki to Pagure issues for machine-readable tracking. Scale notes: the project sees ~30 changes per release and 200+ weekly contributors. Examples: a DNF telemetry plan becomes a privacy-preserving DNF UUID opt-in bit instead of persistent IDs, and an unannounced core package change nearly breaks the beta and triggers a QA hero effort.
AI-written summary · about
chapters (24)
- 0:00Introduction
- 0:15Agenda
- 0:50What is change
- 1:25Why have a change process
- 1:59Process size
- 3:00Example
- 5:03Who gets a voice
- 6:35Who has the vote
- 7:33Democracy is messy
- 9:02How changes are enforced
- 11:17The change process
- 12:51Fedoras features process
- 14:47Different types of features
- 15:47Changes process
- 17:17Systemwide changes
- 18:02General flow
- 19:55Open decision framework
- 24:20Timeline
- 25:08Fedora
- 25:57DNF
- 27:46QA failure
- 28:47Future of the process
- 30:41Summary
- 35:33QA
related talks
47m35 Fedora releases in 35 minutes: a look back with lessons for any project
47m35 Fedora Releases in 30 Minutes (plus Q&A!)
41mSteady and Deliberate: Enabling Contributions in a Regulated Industry
29mOpen Source Contribution - How does it even work?
23mKeep cool and maintain an open source project
34mFOSS like a Boss!
36mState of Open Source in 2024
01h 09m35 Fedora Releases in 30 Minutes (plus Q&A)