Puncte:1

procesul de decizie privind adăugarea pachetelor la repos-urile ubuntu

drapel cn

Există documentație privind procesul de luare a deciziilor pentru ceea ce este inclus în repos-urile „oficiale”? Nu încerc să fac lobby pentru ca pachetul meu preferat să fie inclus și știu că pot adăuga repoziții externe pentru a obține alt software. Mă interesează doar criteriile de includere a software-ului care va fi ridicat cu „stoc” /etc/apt/sources.list fişier.

Software-ul trebuie adăugat/eliminat în timp. De exemplu, python3.8 este disponibil pe bionic. Data de lansare a lui Python3.8 din 14 octombrie 2019 este după data lansării Bionic din 26 aprilie 2018. Înseamnă asta că ar trebui să ne așteptăm ca python3.10 să fie lansat pentru versiunile de Ubuntu acceptate în prezent?

Din nou, sunt mai puțin interesat de specificul unui anumit pachet sau de modul de a adăuga un repo decât de procesul general de luare a deciziilor. Încerc doar să îmi dau seama cum să mă gândesc la ce să mă aștept în arhiva ubuntu.com față de terțe părți.

Indicații către documentația relevantă ar fi binevenite. TIA!

p.s. Cineva a sugerat că o altă întrebare despre ce este o lansare rulantă ar răspunde la întrebare. Nu are nimic de-a face cu această întrebare. Este vorba strict despre procesul de luare a deciziilor, nu despre mecanică. Înțeleg diferențele dintre modele, sunt interesat de modul în care s-a decis ca un nou pachet este inclus în versiunea oficială. Complet ortogonal cu modelul de eliberare rulanta.

user535733 avatar
drapel cn
Începeți cu https://wiki.ubuntu.com/UbuntuDevelopment/ReleaseProcess. Este o pagină veche, dar cea mai mare parte este încă valabilă. Ea explică cea mai mare parte a ceea ce pari să cauți.
user535733 avatar
drapel cn
Exemplul python pare invalid: o instalare stoc de 18.04.x ​​va avea Python 3.6 (nu 3.8). Voluntarii comunității au pus la dispoziție pachetele Py3.8 pentru 18.04 (de aceea acele pachete sunt în -univers în loc de -main). Dacă voluntarii comunității au chef să facă aceeași muncă pentru Py3.10, atunci acele pachete vor fi și ele disponibile.
user535733 avatar
drapel cn
„*Software-ul trebuie adăugat/eliminat în timp*” -- doar în jurul marginilor. Ubuntu debs utilizează o metodă de lansare *snapshot*, nu o lansare *rolling*.Pachetele din 18.04 vor rămâne în mare parte neschimbate pe toată durata lansării. Așa sunt concepute să funcționeze debs. Fără adăugiri, fără eliminări. Excepții: remedieri de erori, erori de securitate, actualizări ale nucleului și câteva aplicații cheie (cum ar fi browserele web). Snaps-urile funcționează diferit -- conțin propriile dependențe și se pot actualiza în orice moment. Snaps-urile folosesc metoda de actualizare *rolling*, astfel încât utilizatorii de snap folosesc întotdeauna cea mai nouă versiune.
user535733 avatar
drapel cn
Deși puteți adăuga repoziții externe, rareori este o soluție bună să cereți utilizatorilor finali să tasteze acele incantații magice și există și alte probleme. În general, sugerăm ca acele proiecte din amonte să-și adauge pur și simplu codul și să construiască rețeta în Debian, de unde vor fi îmbinate automat în Ubuntu. Pentru proiectele care se schimbă rapid, Snaps-urile reprezintă o modalitate ușoară de a oferi cea mai nouă versiune cu ușurință pe distribuții și platforme. Personal, cred că este ciudat că proiectele din amonte recreează probleme de distribuție pe care le-am rezolvat acum 20 de ani.
karel avatar
drapel sa
Răspunde asta la întrebarea ta? [Ubuntu Rolling Release Model](https://askubuntu.com/questions/265680/ubuntu-rolling-release-model)
Puncte:3
drapel cn

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!

drapel cn
mulțumesc @user535733 - aceasta și comentariile tale anterioare sunt utile.

Postează un răspuns

Majoritatea oamenilor nu înțeleg că a pune multe întrebări deblochează învățarea și îmbunătățește legătura interpersonală. În studiile lui Alison, de exemplu, deși oamenii își puteau aminti cu exactitate câte întrebări au fost puse în conversațiile lor, ei nu au intuit legătura dintre întrebări și apreciere. În patru studii, în care participanții au fost implicați în conversații ei înșiși sau au citit transcrieri ale conversațiilor altora, oamenii au avut tendința să nu realizeze că întrebarea ar influența – sau ar fi influențat – nivelul de prietenie dintre conversatori.