Skip to content
leviport edited this page May 8, 2020 · 2 revisions

Welcome to the Pop!_OS GitHub wiki! This is a space for development process documentation. For user documentation, see Pop!_Docs.

Pop!_OS

Pop!_OS is designed for people who use their computer to create; whether it’s complicated, professional grade software and products, sophisticated 3D models, computer science in academia, or makers working on their latest invention. The Pop! user interface stays out of the way while offering extensive customization to perfect your work flow. Built on Ubuntu, you have access to vast repositories of open source software and development tools.

Pop!_OS’s first release was on October 19th, 2017. For more information, visit the Pop!_OS website and view the Pop!_OS documentation.

Project Structure

Pop!_OS is developed by System76. It is the default OS for System76 computers, but is also intended to be useful to users of other hardware. While we welcome and encourage community input, Pop!_OS is driven by System76 and our customers' needs. Read more about our development approach.

Repositories

We maintain a list of Pop!_OS repositories in REPOS.md. Each repository should have a relevant README.md with more information, TESTING.md with QA testing information, CODE_OF_CONDUCT.md that links to our Code of Conduct, and appropriate GitHub issue and PR templates.

Feature Requests

We use the Pop!_OS subreddit to discuss and request features. This allows both System76 employees and Pop! community members to chime in, and helps us gauge interest without overwhelming our issue trackers. With our development approach, we don't manage feature requests from the community or general public in our GitHub projects.

If a feature request is filed against a repo on GitHub, we'll typically close it and ask that it be discussed on the subreddit.

Hardware Enablement

Pop!_OS relies on the upstream projects like Linux, Debian, and Ubuntu for general hardware enablement (outside of System76 hardware). If changes to Pop!_OS have broken something that works in upstream Ubuntu, however, we'll do our best to fix that.

Issue Lifecycle and Workflow

  • New issue →
  • Triaged (assigned to the correct repo) →
    • Added to a project (prioritized for work by System76 employees),
    • Upstream (labeled, kept open, and monitored until fixed upstream),
    • Not Priority (labeled help wanted, but not assigned to a project), or
    • Doesn’t align with our goals (issue closed, references/rationale provided)
  • Issue fixed →
  • Built in Staging repo (not expected to be tested or moved into release, i.e. daily builds) →
  • Fix moved to proposed (needs testing, expected to be released once it’s tested) →
  • QA test signoff →
  • Released to Stable repo (and to users)

Being a Good Upstream

Good upstreams are:

  • Responsive
  • Able to accept differences
  • Willing to explain decisions
  • Compatible with (competing) open source projects when possible
  • Consistent vision & responses, honest responses with references
  • Engaged with downstreams
  • Maintainers of quality code, testing, and documentation
  • Able to provide clear documentation and paths to contribution
  • Good mentors to contributors
  • Willing to accept patches
  • Willing and able to expose their workflow, roadmap, and vision
  • Providers of clear, consistent places to get documentation and contribution info

We strive to both be a good upstream and work with good upstreams as much as possible!