Is there documentation on the decision making process for what gets included in "official" repos? I’m not trying to lobby to get my favorite package to be included and I know I can add external repos to get other software. I’m only interested in the criteria for including software that will be picked up with the "stock" /etc/apt/sources.list file.
Software must get added/removed over time. For example, python3.8 is available on bionic. Python3.8’s release date of 14 October 2019 is after bionic’s release date of April 26, 2018. Does that mean we should expect python3.10 to be released for currently supported versions of Ubuntu?
Again, I’m less interested in the specifics of a particular package or how to add a repo than I am in the overall decision making process. I’m just trying to figure out how to think about what to expect in the ubuntu.com archive versus third-party.
Pointers to relevant documentation would be welcome. TIA!
p.s. Someone suggested that another question about what a rolling release is would answer the question. That has nothing to do with this question. This is strictly about the decision making process, not the mechanics. I understand the differences in the models, I’m interested in how it’s decided a new package gets included in the official release. Completely orthogonal to the rolling release model.
>Solution :
What gets "included" into the Ubuntu Deb repositories is actually pretty simple: It’s what Debian has available for merging.
Early in each Release Cycle, during the Planning phase, the community of developers, engineers, and volunteers meet and agree on what version of each package will be in the next release. Usually, that version is simply what’s currently in Debian Testing or Debian Unstable.
- While there can be disagreement in some of these discussion, there is rarely acrimony: Foo 1.2 simply isn’t different enough from Foo 1.1 to get too excited. Also, the people in these planning sessions are the same developers, engineers, and volunteers who will do the actual work.
For complex projects (like Python), version planning occurs several cycles ahead so the workload matches the resources. It takes a lot of people working together to build and test a Python update!
Note that more community volunteers involved with Debian packaging results in a greater variety of software available in Ubuntu, and newer versions available sooner. Conversely, less volunteer participation means less software and older software. Packaging deb software is a great way to get involved, contribute to the community, and help others!