Join Log in
Score:1
avatar Ubuntu

decision process around adding packages to ubuntu repos

cn flag
keithpjolley

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.

28
0 + 0
user535733 avatar
cn flag
user535733
Start with https://wiki.ubuntu.com/UbuntuDevelopment/ReleaseProcess. It's an old page, but most of it is still valid. It explains most of what you seem to be looking for.
0
Reply
user535733 avatar
cn flag
user535733
The python example seems invalid: A stock install of 18.04.x will have Python 3.6 (not 3.8). Community volunteers have made Py3.8 packages available for 18.04 (that's why those packages are in -universe instead of -main). If community volunteers feel like doing the same work for Py3.10, then those packages will also be available.
0
Reply
user535733 avatar
cn flag
user535733
"*Software must get added/removed over time*" -- only around the edges. Ubuntu debs use a *snapshot* release method, not a *rolling* release. The packages in 18.04 will be mostly unchanged for the life of the release. That's how debs are designed to work. No additions, no removals. Exceptions: Bugfixes, security bugs, kernel updates, and a couple key applications (like web browsers). Snaps work differently -- they contain their own dependencies and can update at any time. Snaps use the *rolling* update method, so snap users are always using the newest version.
0
Reply
user535733 avatar
cn flag
user535733
While you can add external repos, it's rarely a good solution to ask end users to type those magic incantations, and there are other problems. Generally, we suggest that those upstream projects simply add their code and build recipe to Debian, whence they will be merged into Ubuntu automatically. For rapidly-changing projects, Snaps are an easy way to offer the newest release easily across distros and platforms. Personally, I think it's weird that upstream projects are re-creating distribution problems that we solved 20 years ago.
0
Reply
karel avatar
sa flag
karel
Does this answer your question? [Ubuntu Rolling Release Model](https://askubuntu.com/questions/265680/ubuntu-rolling-release-model)
0
Reply
Score:3
user535733 avatar Ubuntu
cn flag
user535733

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!

0 + 0
cn flag
keithpjolley
thanks @user535733 - this and your previous comments are helpful.
0
Reply
ธงชาติไทย
Elon Musk
I sit in a Tesla and translated this thread with Ai:

mangohost

Post an answer

Most people don’t grasp that asking a lot of questions unlocks learning and improves interpersonal bonding. In Alison’s studies, for example, though people could accurately recall how many questions had been asked in their conversations, they didn’t intuit the link between questions and liking. Across four studies, in which participants were engaged in conversations themselves or read transcripts of others’ conversations, people tended not to realize that question asking would influence—or had influenced—the level of amity between the conversationalists.